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Preface 



This volume contains the proceedings of EKAW 2000 (12th International Confe- 
rence on Knowledge Engineering and Knowledge Management), held in Juan-les- 
Pins, on 2-6 October. Previously, EKAW was the European Knowledge Acquisi- 
tion Workshop. In 1997, it had evolved towards the European Workshop on Kno- 
wledge Acquisition, Modeling and Management. Since 2000, EKAW has become 
an open conference, focusing on knowledge engineering and knowledge manage- 
ment. It aims at gathering researchers working in any area concerning methods, 
techniques and tools for the construction and the exploitation of knowledge- 
intensive systems and for knowledge management. EKAW 2000 attracted nume- 
rous submissions of papers, from all over the world. 

Research in knowledge engineering tries to offer some answers to the following 
questions: 

— How to build knowledge-intensive systems, such as expert systems, know- 
ledge-based systems, or knowledge management systems? In the past years, 
strong advances in knowledge engineering consisted of methodologies and 
tools for supporting knowledge acquisition from human experts and for sup- 
porting knowledge-level modeling of knowledge-based systems. In the last 
years, there was a strong emphasis on ontologies and problem-solving me- 
thods, with the aim of enhancing knowledge reusability. Knowledge enginee- 
ring can also benefit from machine learning techniques that can be helpful for 
automatic building of a knowledge base (for example, automatic knowledge 
acquisition from textual sources of information) . 

— How to evaluate knowledge-intensive systems, with both qualitative and 
quantitative measures, according to various criteria (user-centered criteria, 
quantitative criteria, etc.)? 

— How to make knowledge-intensive systems evolve? Cooperation with the sta- 
keholders involved and machine learning are examples of approaches helpful 
for evolution and refinement of a knowledge base. 

We have noticed the following current trends in knowledge engineering: 

— There is a growing importance for knowledge management as a privileged 
application of knowledge engineering methodologies and techniques. Know- 
ledge management aims at capturing and representing individual or collective 
knowledge in organizations or communities, in order to enhance knowledge 
access, sharing and reuse. Therefore knowledge management is a privileged 
potential application of knowledge engineering. But other communities (such 
as Computer Supported Cooperative Work (CSCW)) have been involved in 
knowledge management for years - even before the knowledge engineering 
community. The need for a multidisciplinary approach and other techniques 
stemming from these other communities is recognized more and more. Such 
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communities emphasize the cooperative and organizational approaches for 
knowledge management. 

— The exploitation of texts and documents either as sources from which a 
knowledge base can be built, or as way of materializing organizational me- 
mory led to a growing significance of knowledge acquisition from texts or 
text mining. This is possible thanks to the recent advances in natural lan- 
guage processing techniques, and thanks to cooperation between knowledge 
engineering and linguistics communities. 

— There is a growing influence of the Web, both as a fabulous source of kno- 
wledge and as a fabulous means of knowledge diffusion. It enables a con- 
vergence with the research of other communities (e.g. database community, 
information retrieval community, and text mining), which try to contribute 
to the semantic Web. The Web also raises new problems that are challenging 
to the knowledge engineering community. 

— Ontology engineering continues to play an essential role in research on know- 
ledge engineering, as confirmed by the papers published in these proceedings. 
They aim at answering the following questions: What methodology should 
be used for building an ontology? In particular, how can it exploit knowledge 
acquisition from texts with the support of natural language processing tools? 
How can ontologies be specified and exchanged (in particular, through the 
Web)? Since standards are important, how can we compare the languages 
proposed by the knowledge engineering community for modeling and forma- 
lizing knowledge with respect to the existing recommendations of W3C for 
the semantic Web, such as resource description framework (RDF) and RDF 
Schema? How can we reuse existing ontologies? What influence does reuse 
have on ontology life cycle? How can we integrate several ontologies, possibly 
cooperatively? 

— Cross-fertilization between knowledge engineering and other disciplines such 
as software engineering, linguistics, CSCW, and machine learning, is not new 
but continues to be promising. 

These are the main trends of research in knowledge engineering, as they 
appear in the papers accepted at EKAW 2000. These papers are gathered into 
the following topics: 

— Knowledge modeling languages and tools, 

— Ontologies, 

— Knowledge acquisition from texts, 

— Machine learning, 

~ Knowledge management and e-commerce, 

~ Validation, evaluation, certification, 

— Problem-solving methods, 

— Knowledge representation and 

— Methodologies. 

The main lesson about these current trends in knowledge engineering is the 
confirmation of the need to remain open to other communities, to new techno- 
logies or to new kinds of applications. 
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Abstract. Currently computers are changing from single isolated devices into 
entry points into a worldwide network of information exchange and business 
transactions. Support in data, information, and knowledge exchange is becoming 
the key issue in current computer technology. Ontologies will play a major role in 
supporting information exchange processes in various areas. A prerequisite for 
such a role is the development of a joint standard for specifying and exchanging 
ontologies. The purpose of the paper is precisely concerned with this necessity. 

We will present OIL, which is a proposal for such a standard. It is based on 
existing proposals such as OKBC, XOL and RDF schema, enriching them with 
necessary features for expressing ontologies. The paper sketches the main ideas of 
OIL. 

1 Introduction 

Currently, we are on the brink of the second Web generation. The Web started with 
mainly handwritten HTML pages; then the step was made to machine generated and 
often active HTML pages. This first generation of the Web was designed for direct 
human processing (reading, browsing, form-filling, etc.). The second generation Web, 
that we could call the “Knowledgeable Web”, aims at the machine processable 
interpretation of information. This coincides with the vision that Tim Bemers-Lee calls 
the Semantic Web in his recent book “Weaving the Web”, and for which he uses the 
slogan “Bringing the Web to its full potential”. The Knowledgeable Web will enable 
intelligent services such as information brokers, search agents, information filters etc. 
Ontologies will play a crucial role in enabling the processing and sharing of knowledge 
between programs on the Web. 

Ontologies are a popular research topic in various communities, such as knowledge 
engineering, natural language processing, cooperative information systems, intelligent 
information integration, and knowledge management. They provide a shared and 
common understanding of a domain that can be communicated between people and 
application systems. They have been developed in Artificial Intelligence to facilitate 
knowledge sharing and reuse. Ontologies are generally defined as a “representation of a 
shared conceptualisation of a particular domain”. Recent articles covering various 
aspects of ontologies can be found in [43], [26], [22], [14]. 

R. Dieng and O. Corby (Eds.): EKAW 2000, LNAI 1937, pp. 1-16, 2000. 
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The On-To-Knowledge' project will develop methods and tools to employ the full 
power of the ontological approach to facilitate Web-based knowledge use, knowledge 
access and knowledge management. The On-To-Knowledge tools will help knowledge 
workers who are not IT specialists to access company-wide information repositories in 
an efficient, natural and intuitive way. The technical backbone of On-To-Knowledge is 
the use of ontologies for the various tasks of information integration and mediation. The 
first major spin-off from the On-To-Knowledge project is OIL (the Ontology Inference 
Layerf'. OIL is a Web-based representation and inference layer for ontologies, which 
combines the widely used modeling primitives from frame-based languages with the 
formal semantics and reasoning services provided by description logics. Furthermore, 
OIL is the first ontology representation language that is properly grounded in W3C 
standards such as RDF/RDF-schema and XML/XML-schema. 

It is envisaged that this core language will be extended in the future with sets of 
additional primitives. A more detailed discussion of OIL, including formal semantics 
and syntax definitions in RDF and XML, is provided in [28]. 

The content of this paper is organized as follows. Section 2 provides the underlying 
rationales of OIL. Section 3 provides the language primitives of OIL and discusses tool 
support. We also sketch possible directions in extending OIL. Section 4 compares OIL 
with other ontology languages and web standards. Finally, a short summary is provided 
in Section 5. 

2 OIL = Our Ideas of a Language 

In this Section, we will first explain the three roots upon which OIL was based. Then we 
will show why the existing proposal for an ontology exchange language (Ontolingua, 
[24], [13]) is not very well-defined. Then the relationships of OIL with OKBC and RDF 
are sketched out. These are discussed further in Section 4. 

2.1 The three roots of OIL 

OIL unifies three important aspects provided by different communities (see Figure 1): 
Formal semantics and efficient reasoning support as provided by Description Logics, 
epistemological rich modeling primitives as provided by the Frame community, and a 
standard proposal for syntactical exchange notations as provided by the Web 
community. 

Description Logics (DL). DLs describe knowledge in terms of concepts and role 
restrictions that are used to automatically derive classification taxonomies. The main 
effort of research in knowledge representation is in providing theories and systems for 
expressing structured knowledge, for accessing it and reasoning with it in a principled 
way. DLs (cf [7], [2]), also known as terminological logics, form an important and 
powerful class of logic-based knowledge representation languages.^ They result from 
early work on semantic networks and define a formal and operational semantics for 



1. www.ontoknowledge.org 

2. www.ontoknowledge.org/oil 
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them. DLs try to find a fragment of first-order logie with high expressive power which 
still has a decidable and efficient inference procedure (cf [38]). Implemented systems 
inelude BACK, CLASSIC, CRACK, FLEX, K-REP, KL-ONE, KRIS, LOOM, and 
YAK.^ A distinguishing feature of DLs is that classes (usually called concepts) can be 
defined intensionally in terms of descriptions that specify the properties that objects 
must satisfy in order to belong to the coneept. These descriptions are expressed using a 
language that allows the construction of composite descriptions, including restrictions 
on the binary relationships (usually called roles) connecting objects. Various studies 
examine extensions of the expressive power for such languages and the trade-off in 
computational complexity for deriving is-a relationships between concepts in such a 
logic (and also, although less commonly, the complexity of deriving instance-of 
relationships between individuals and concepts). In spite of discouraging theoretical 
complexity results, there are now efficient implementations for DL languages (cf [6], 
[35], [29]), see for example DLP^ and the FaCT system.^ OIL inherits from Description 
Logic its formal semantics and the efficient reasoning support developed for these 
languages. In OIL, subsumption is deeidable and with FaCT we ean provide an efficient 
reasoner for this. In general, subsumption is only one of several reasoning tasks for 
working with an ontology. Others are: instance classification, query subsumption and 
query answering over classes and instances, navigation through ontologies, etc. 
However, many of them can be reformulated in terms of subsumption checking. Others 
may lead to different super- and subsets of the current OIL language version. The 
current version of OIL can be seen as a starting point for exploring the space of possible 
choices in designing Ontology exchange languages and characterizing them in terms of 
their pros and cons. 




3. http://dl.kr.org/. Here links to most papers, project, and research events in this area can be 
found. 

4. http://www.research.att.com/sw/tools/classic/imp-systems.html 

5. http://www.bell-labs.com/user/pfps/ 

6. http://www.es. man.ac.uk/'horrocks/software.html We will discuss later in the paper the use of 
FaCT as an inference engine for OIL. 
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Frame-based systems. The central modeling primitive of predicate logic are 
predicates. Frame-based and object-oriented approaches take a different approach. 
Their central modeling primitive are classes (i.e., frames) with certain properties called 
attributes. These attributes do not have a global scope but are only applicable to the 
classes they are defined for (they are typed) and the “same” attribute (i.e., the same 
attribute name) may be associated with different range and value restrictions when 
defined for different classes. A frame provides a certain context for modeling one aspect 
of a domain. Many other additional refinements of these modeling constructs have been 
developed, and this has contributed to the incredible success of this modeling paradigm. 
Many frame-based systems and languages have been developed, and under the name 
object-orientation it has conquered the software engineering community. Therefore, 
OIL incorporates the essential modeling primitives of frame-based systems into its 
language. OIL is based on the notion of a class and the definition of its superclasses and 
attributes. Relations can also be defined not as attributes of a class but as an independent 
entities having a certain domain and range. Like classes, relations can be arranged in a 
hierarchy. We will explain the difference between OIL and pure Description Logics 
using their different treatment of attributes. In DLs, roles are not defined for concepts. 
Actually, concepts are defined as subclasses of role restriction. One could rephrase this 
in a frame context as follows: a class is a subclass of its attribute definitions (i.e., all 
instances of the class must fulfil the restrictions defined for the attributes). However, 
asking which roles could be applied to a class does not make much sense for a DL as 
nearly all slots can be applied to a class. With frame-based modeling one makes the 
implicit assumption that only those attributes can be applied to a class that are defined 
for this class. 

Web standards: XML and RDF. Modeling primitives and their semantics are one 
aspect of an Ontology Exchange Language. In addition, you have to decide about its 
syntax. Given the current dominance and importance of the WWW, a syntax of an 
ontology exchange language must be formulated using existing web standards for 
information representation. As already proven with XOL^ (cf [30], [34]), XML can be 
used as a serial syntax definition language for an ontology exchange language. The 
BioOntology Core Group^ recommends the use of a frame-based language with an 
XML syntax for the exchange of ontologies for molecular biology. The proposed 
language is called XOL. The ontology definitions that XOL is designed to encode 
include both schema information (meta-data), such as class definitions from object 
databases, as well as non-schema information (ground facts), such as object definitions 
from object databases. The syntax of XOL is based on XML, and the modeling 
primitives and semantics of XOL are based on OKBC-Lite. OIL is closely related to 
XOL and can be seen as an extension of XOL. For example, XOL allows only necessary 
but not sufficient class definitions (i.e., a new class is always a sub-class of and not 
equal to its specification) and only class names, but not class expressions (except for the 
limited form of expression provided by slots and their facets) can be used in defining 
classes. The XML syntax of OIL was mainly defined as an extension of XOL, although, 
as we said above for OKBC, we omit some of the original language primitives. More 



7 . http : //www. ai . sri . com/ pkarp/xol/. 

8. http://smi-web.stanford.edu/projects/bio-ontology/ 
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details on the XML syntax of OIL (defined as a DTD and in XML schema) can be found 
in[28]and [31], 

Other candidates for a web-based syntax for OIL are RDF and RDFS. The Resource 
Description Framework (RDF)^ (cf [36], [32]) provides a means for adding semantics 
to a document without making any assumptions about the structure of the document. 
RDF is an infrastructure that enables the encoding, exchange and reuse of structured 
metadata. RDF schemes (RDFS) [8] provide a basic type schema for RDF. Objects, 
Classes, and Properties can be described. Predefined properties can be used to model 
instance of and subclass of relationships as well as domain restrictions and range 
restrictions of attributes. In regard to ontologies, RDF provides two important 
contributions: a standardized syntax for writing ontologies and a standard set of 
modeling primitives, like instance of and subclass of relationships. 

2.2 Why not Ontolingua? 

Ontolingua^® (cf [24], [13]) is an existing proposal for a ontology exchange language. 
It was designed to support the design and specification of ontologies with a clear logical 
semantics based on KIF'^ Ontolingua extends KIF with additional syntax to capture 
intuitive bundling of axioms into definitional forms with ontological significance; and a 
Frame Ontology to define object-oriented and frame-language terms. The set of KIF 
expressions that Ontolingua allows is defined in an ontology, called the Frame 
Ontology. The Frame Ontology specifies in a declarative form the representation 
primitives that are often supported with special-purpose syntax and code in object- 
centered representation systems (e.g., classes, instances, slot constraints, etc.). 
Ontolingua definitions are Lisp-style forms that associate a symbol with an argument 
list, a documentation string, and a set of KIF sentences labeled by keywords. An 
Ontolingua ontology is made up of definitions of classes, relations, functions, objects 
distinguished, and axioms that relate these terms. 

The problem with Ontolingua is its high expressive power that is provided without any 
means to control it. Not surprisingly, no reasoning support has ever been provided for 
Ontolingua. OIL takes the opposite approach. We start with a very simple and limited 
core language. The web has proven that restriction of initial complexity and controlled 
extension when required is a very successful strategy. OIL takes this lesson to heart. We 
already mentioned that the focus on different reasoning tasks may lead to different 
extensions. We also showed in [18] serious shortcomings in the expressiveness of OIL. 
This process may finally lead to one version of OIL with similar expressiveness as 
Ontolingua. Still we would have had a process of rational reconstruction that makes 
certain choices with their pros and cons explicitly. Second, we would still have versions 
with smaller expressive power for cases they can be applied to. 



9. http://www.w3c.org/Metadata/ 

10. http://ontolingua.stanford.edu/ 

11. The Knowledge Interchange Format KIF ([20], [21]) is a language designed for use in the 
interchange of knowledge among disparate computer systems. KIF is based on predicate logic but 
provides a Lisp-oriented syntax for it. 

12. The Ontolingua Server as described in [13] has extended the original language by providing 
explicit support for building ontological modules that can be assembled, extended, and refined in 
a new ontology. 
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In general there are two strategies to achieve a standard: Defining a “small” set of 
modeling primitives that are consensus in the community and define a proper semantics 
for them; or defining a “large” set of modeling primitives that are present in some of the 
approaches in a community and glue them together. Both may lead to success. The first 
approach can be illustrated with HTML. Its first version was very simple and limited but 
therefore allowed the Web to catch on and become a world wide standard. Meanwhile 
we have HTML version 4, XHTML, and XML. So beginning with a core set and 
successively refining and extending them has proven to be successful strategy. The 
second approach has been taken by the UML community by designing a model that is 
broad enough to cover all modeling concepts of a community. This leads to ambiguity 
and redundancy in modeling primitives and sometimes a precise semantic definition is 
lacking. However, UML has been adopted by Software industry as one of the major 
approaches, and is therefore a success too. Obviously these two opposed approaches to 
standardization may both work successfully. We have chosen the first approach in 
developing OIL. This stems from the purpose OIL is designed for. It should provide 
machine understandable semantics of domain theories. This will be used in the Web 
context to provide machine processable semantics of information sources helping the 
make true Tim Berners-Lee’s vision of a semantic web. Therefore clear definitions of 
semantics and reasoning support is essential. 

2.3 OIL and OKBC 

A simple and well-defined semantics is of great importance for an ontology exchange 
language because it is used to transfer knowledge from one context to another. There 
already exists an ontology exchange standard for frame-based systems, the Open 
Knowledge Base Connectivity (OKBC)^^ ([9], [10]). OKBC is an API (application 
program interface) for accessing frame-based knowledge representation systems. Its 
knowledge model supports features most commonly found in frame-based knowledge 
representation systems, object databases, and relational databases. OKBC-Lite extracts 
most of the essential features of OKBC, while not including some of its more complex 
aspects. OKBC has also been chosen by FIPA^^ as an exchange standard for ontologies 
(cf FIPA 98 Specification, Part 12: Ontology Service [19]). OIL shares many features 
with OKBC and defines a clear semantics and XML-oriented syntax for them. A 
detailed comparison is made later in this document. 

2.4 OIL and RDF 

In the same way that OIL provides an extension to OKBC (and is therefore downward 
compatible with OKBC) it also provides an extension to RDF and RDFS. Based on its 
RDF syntax, ontologies written in OIL are valid RDF documents. OIL extends the 
schema definition of RDFS by adding additional language primitives not yet present in 
RDFS. Based on these extensions an ontology in OIL can be expressed in RDFS. 



13. http://www.ai. sri.cotn/'okbc/ 

14. http://www.fipa.org 
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3 The OIL Language 

This section provide an informal description of the modeling primitives, its tool 
environment, and a discussion of future extensions of OIL. The semantics of OIL is 
described in [28]. 

3.1 An informal description of OIL 

An OIL ontology is a structure made up of several components, some of which may 
themselves be structures, some of which are optional, and some of which may be 
repeated. We will write component' to indicate an optional component, component 
to indicate a component that may be repeated one or more times (i.e., that must occur at 
least once) and component to indicate a component that may be repeated zero or more 
times (i.e., that may be completely omitted). 

When describing ontologies in OIL we have to distinguish three different layers: 

• The object level where concrete instances of an ontology are described. We do not 
deal with this level in this paper. The exchange of application-specific information 
on instances is currently beyond the scope of OIL. 

• The first metalevel, where the actual ontological definitions are provided. Here we 
define the terminology that may be populated at the object level. OIL is mainly 
concerned wifh this level. It is a means for describing a structured vocabulary with 
well-defined semantics. The main contribution of OIL is in regard to this level. 

• The second metalevel (i.e., the meta-metalevel) is concerned with describing 
features of such an ontology like author, name, subject, etc. For representing 
metadata of ontologies we make use of the DublinCore Meta data Element Set 
(Version 1.1) [1 1] standard. The Dublin Core is a meta-data element set intended 
to facilitate the discovery of electronic resources. Originally conceived for author- 
generated descriptions of web resources, it is now widely used and has attracted 
the attention of resource description communities such as museums, libraries, 
government agencies, and commercial organizations. 

OIL is concerned with the first and second metalevels. The former is called ontology 
definition and the latter is called ontology container. We will discuss both elements of 
an ontology specification in OIL. We start with the ontology container and will then 
discuss the backbone of OIL, the ontology definition. 

Ontology Container: We adopt the components as defined by Dublin Core Meta data 
Element Set, Version 1.1 for the ontology container part of OIL. Although every 
element is optional and repeatable in the Dublin Core set, in OIL some elements are 
required or have a predefined value. Required elements are written as element^. Some 
of the elements can be specialized with a qualifier, which refines the meaning of that 
element. In our shorthand notation we will write element, qualifier. The precise syntax 
based on RDF is given in [37]. 

Apart from various header fields encapsulated in its container, an OIL ontology consists 

of a set of definitions: 

• import ■ A list of references to other OIL modules that are to be included in this 
ontology. XML schemas and OIL provide the same (limited) means for 
composing specifications. You can include specifications and the underlying 
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assumption is that names of different specifications are different (via different 
prefixes). 

• rule-base' A list of rules (sometimes called axioms or global constraints) that 
apply to the ontology. At present, the structure of these rules is not defined (they 
could be horn clauses, DL style axioms etcetera), and they have no semantic 
significance. The rule base consists simply of a type (a string) followed by the 
unstructured rules (a string). 

• class and slot definitions Zero or more class definitions (class-def) and slot 
definitions (slot-del), the structure of which will be described below. 

A class definition (class-def) associates a class name with a class description. A class- 
def consists of the following components: 

• type ■ The type of definition. This can be either primitive or defined; if omitted, 
the type defaults to primitive. When a class is primitive, its definition (i.e., the 
combination of the following subclass-of and slot-constraint components) is 
taken to be a necessary but not sufficient condition for membership of the class. 

• name The name of the class (a string). 

• documentation Some documentation describing the class (a string). 

• subclass-of' A list of one or more class-expressions, the structure of which will 
be described below. The class being defined in this class-def must be a sub-class 
of each of the class-expressions in the list. 

• slot-constraints Zero or more slot-constraints, the structure of which will be 
described below. The class being defined in this class-def must be a sub-class of 
each of the slot-constraints in the list. 

A class-expression can be either a class name, a slot-constraint, or a boolean 
combination of class expressions using the operators AND, OR or NOT. Note that class 
expressions are recursively defined, so that arbitrarily complex expressions can be 
formed. 

A slot-constraint (a slot may also be called a role or an attribute) is a list of one or 
more constraints (restrictions) applied to a slot. A slot is a binary relation (i.e., its 
instances are pairs of individuals), but a slot-constraint is actually a class definition — its 
instances are those individuals that satisfy the constraint(s). A slot-constraint consists 
of the following components: 

• name A slot name (a string). The slot is a binary relation that may or may not be 
defined in the ontology. If it is not defined it is assumed to be a binary relation 
with no globally applicable constraints, i.e., any pair of individuals could be an 
instance of the slot. 

• has-value ' A list of one or more class-expressions. Every instance of the class 
defined by the slot-constraint must be related via the slot relation to an instance of 
each class-expression in the list. For example, the value constraint: 

slot-constraint eats 

has-value zebra, wildebeest 

defines the class each instance of which eats some instance of the class zebra 
and some instance of the class wildebeest. Note that this does not mean that 
instances of the slot-constraint eat only zebra and wildebeest: they may also be 
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partial to a little gazelle when they can get it. Has-value expresses the existential 
quantifier of Predicate logic and a necessary condition. An instance of a class 
must have at most one value for this slot that fulfils its range restriction. 

• value-type ' A list of one or more class-expressions. If an instance of the class 
defined by the slot-constraint is related via the slot relation to some individual x, 
then X must be an instance of each class-expression in the list. For example, the 
value-type constraint: 

slot-constraint eats 
value-type meat 

defines the class each instance of which eats nothing that is not meat. Note that 
this does not mean that instances of the slot-constraint eat anything at all. value- 
type expresses the all quantifier of Predicate logic and a sufficient condition. If an 
instance of a class has a value for this slot, then it must fulfil its range restriction. 

• max-cardinality ' A non-negative integer n followed by a class-expression. An 
instance of the class defined by the slot-constraint can be related to at most n 
distinct instances of the class-expression via the slot relation. 

• min-cardinality ■ A non-negative integer n followed by a class-expression. An 
instance of the class defined by the slot-constraint must be related to at least n 
distinct instances of the class-expression via the slot relation. 

A slot definition (slot-def) associates a slot name with a slot description. A slot 
description specifies global constraints that apply to the slot relation, for example that it 
is a transitive relation. A slot-def consists of the following components: 

• name The name of the slot (a string). 

• documentation ' Some documentation describing the slot (a string). 

• subslot-of' A list of one or more slots. The slot being defined in this slot-def 
must be a sub-slot of each of the slots in the list. For example, 

slot-def daughter 
subslot-of child 

defines a slot daughter that is a subslot of child, i.e., every pair of individuals that 
is an instance of daughter must also be an instance of child. 

• domain ' A list of one or more class-expressions. If the pair (x,y) is an instance 
of the slot relation, then x must be an instance of each class-expression in the list. 

• range ' A list of one or more class-expressions. If the pair (x,y) is an instance of 
the slot relation, then y must be an instance of each class-expression in the list. 

• inverse^ The name of a slot S that is the inverse of the slot being defined. If the 
pair {x,y) is an instance of the slot S, then {yx) must be an instance of the slot 
being defined. For example, 

slot-def eats 
inverse eaten-by 

defines the inverse of the slot eats to be the slot eaten-by, i.e., if x eats y then y 
is eaten-by x. 

9 

• properties' A list of one or more properties of the slot. Valid properties are: 
transitive and symmetric. 
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3.2 Current Limitations of OIL 

Our starting point has been to define a decidable core language, with the intention that 
additional (and possibly important) features be defined as a set of extensions (still with 
clearly defined semantics). Modelers will be free to use these language extensions, but it 
will be clear that this may compromise decidability and reasoning support. This seems 
to us a cleaner solution than trying to define a single “all things to all men” language. 

In this section we briefly discuss a number of features which are available in other 
ontology modeling languages and which are not or not yet included in OIL. For each of 
these features, we briefly motivate our choice, and mention future prospects where 
relevant. 

Default reasoning: Although OIL does provide a mechanism for inheriting values from 
super-classes, such values cannot be overwritten. As a result, such values cannot be 
used for the purpose of modeling default values. Combining defaults with a well defined 
semantics and reasoning support is known to be problematical. 

Rules/Axioms: As discussed above, only a fixed number of algebraic properties of slots 
can be expressed in OIL. There is no facility for describing arbitrary axioms that must 
hold for all items in the ontology. Such a powerful feature is undoubtedly useful and 
may be added to the core language. 

Modules: We 3.1 presented a very simple construction to modularize ontologies in 
OIL. In fact, this mechanism is identical to the namespace mechanism in XML. It 
amounts to a textual inclusion of the imported module, where name-clashes are avoided 
by prefixing every imported symbol with a unique prefix indicating its original location. 
Future extensions would concern parameterized modules, signature mappings between 
modules, and restricted export interfaces for modules. 

Using instances in class definitions: Results from research in description and modal 
logics show that the computational complexity of such logics changes dramatically for 
the worse when reasoning with domain-instances is allowed (cf. [1]). For this reason 
OIL does not currently allow the use of instances in slot-values, or extensional 
definitions of classes (i.e., class definitions by enumerating the class instances). 
Concrete domains: OIL currently does not support concrete domains (e.g., integers, 
strings, etc.). This would seem to be a serious limitation for a realistic ontology 
exchange language, and extensions of OIL in this direction are probably necessary. The 
theory of concrete domains is well understood [3], and it should be possible to add some 
restricted form of concrete domains without sacrificing reasoning support. 

Limited Second-order expressivity: Many existing languages for ontologies (KIF, 
CycL, Ontolingua) include some form of reification mechanism in the language, which 
allows us to treat statements of the language as objects in their own right, thereby 
making it possible to express statements about these statements. A full second order 
extension would be clearly undesirable (even unification is undecidable in full 2nd 
order logic). However, much weaker second order constructions already provide much 
if not all of the required expressivity without causing any computational problem (in 
effect, they are simply 2nd order syntactic sugar for what are essentially first order 
constructions). 
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3.3 Tools 

OIL makes use of the FaCT (Fast Classification of Terminologies) system in order to 
provide reasoning support for ontology design, integration and verification. FaCT is a 
Description Logic classifier that can also be used for consistency checking in modal and 
other similar logics. FaCT’s most interesting features are its expressive logic (in 
particular the SHIQ reasoner), its optimized tableaux implementation (which has now 
become the standard for DL systems), and its CORBA based client-server architecture. 
FaCT’s optimizations are specifically aimed at improving the system’s performance 
when classifying realistic ontologies, and this results in performance improvements of 
several orders of magnitude when compared with older DL systems. This performance 
improvement is often so great that it is impossible to measure precisely as unoptimised 
systems are virtually non-terminating with ontologies that FaCT is easily able to deal 
with [29]. Taking a large medical terminology ontology developed in the GALEN 
project [40] as an example, FaCT is able to check the consistency of all 2,740 classes 
and determine the complete class hierarchy in about 60 seconds of (450MHz Pentium 
III) CPU time.^^ In contrast, the KRIS system [4] had been unable to complete the same 
task after several weeks of CPU time. 

4 Comparing OIL with other approaches 

This section compares OIL with other frame-based approaches and with the arising web 
standards RDF and RDFS. 

4.1 OIL and other frame-oriented approaches 

The modeling primitives of OIL are based on those of XOL (cf [30]). OIL extends 
XOL so as to make it more suitable for capturing ontologies defined using a logic-based 
approach (such as used in DLs) in addition to the frame-based ontologies for which 
XOL (and OKBC [10]) were designed. The extensions are designed so that most valid 
XOL ontologies should also be valid OIL ontologies. The exceptions are due to the 
omission of constructs for which reasoning support (e.g., for class consistency and 
subsumption checking) could not be provided from OIL, either because their semantics 
are unclear or because their inclusion would lead to the language being undecidable. 

How OIL extends XOL 

It is the frame structure itself that restricts the way language primitives can be combined 
to define a class. In XOL, class definitions consist of the specification of zero or more 
parent classes (from which characteristics are inherited) and zero or more slots — binary 
relations whose characteristics can be additionally restricted using slot facets (e.g., the 
range of the relation can be restricted using the value-type facet). Viewed from a logical 
perspective, each slot (with its associated facets) defines a class (e.g., a slot eats with 
the value-type junk-food defines the class of individuals who eat nothing but junk 
food), and the frame is implicitly'^ the class formed from the conjunction of all the slots 



15. Adding single classes and checking both their consistency and their position in the class 
hierarchy is virtually instantaneous. 

16. The OKBC semantics (on which XOL relies) are less than clear on this and on several other 
important points. 
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and all the parent classes. Consequently, every class must be defined by a conjunction 
of slots (which themselves have a very restricted form) and other named classes. In 
contrast, DLs usually allow language primitives to be combined in arbitrary boolean 
expressions (i.e., using conjunction, disjunction and negation) and allow class 
definitions to be used recursively wherever a class name might appear. Moreover, XOL 
only provides one form of class definition statement. It is not clear whether the resulting 

1 -j 

class is meant to be primitive or non-primitive: we will assume that it is primitive. 

In our view, this very restricted form of class definition makes XOL (and indeed 
OKBC) unsuitable as an ontology exchange language: it makes it impossible to capture 
even quite basic DL ontologies and precludes some very simple and intuitive kinds of 
class definition. For example, it is impossible to define the class of vegetarian as the 
subclass of person such that everything they eat is neither meat nor fish. On the one 
hand, the value of the value-type facet of the slot eats cannot be an expression such as 
“not (meat or fish)”. On the other hand, because vegetarian must be primitive, there 
could be individuals of type person who eat neither meat nor fish but who are not 
classified as vegetarians.^^ Another serious weakness of XOL class definitions (and 
those of OKBC) is that there is no mechanism for specifying disjointness of classes, a 
basic modeling primitive that can be captured even by many conceptual modeling 
formalisms used for database schema design. This makes it impossible to capture the 
fact that the class maie is disjoint from the class female. This is easy for a DL, where 
the class female can simply be made a subclass of “not male”. 

Another weakness of XOL (and OKBC) is that slots (relations) are very much second 
class citizens when compared to classes. In particular, there is no support for a slot 
hierarchy and only restricted kinds of properties that can be specified for relations. For 
example, it is not possible to define the slot has-parent as a subslot of the has- 
ancestor, nor is it possible to specify that has-ancestor is a transitive relation. The 
specification of this kind of slot hierarchy including transitive and non-transitive 
relations is essential in ontologies dealing with complex physically composed domains 
such as human anatomy [41] and engineering [42]. 

How OIL restricts XOL 

As mentioned above, OIL also restricts XOL in some respects: Initially, only conceptual 
modeling will be supported, i.e., individuals are not supported. The slot constraints 
numeric-minimum and uumeric-maximum are not supported. Again, future 
extensions of OIL may support concrete data types (including numbers and numeric 
ranges). Collection types other than set are not supported. Slot inverse can only be 
specified in global slot definitions: naming the inverse of a relation only seems to make 
sense when applied globally. 

4.2 OIL and RDF 

The Resource Description Framework (RDF) [32] is a recommendation of the World 
Wide Web Consortium (W3C) for representing meta-data in the Web. RDF data 



17. In contrast, OKBC supports the definition of both primitive and non-primitive classes. 

18. This aspect of the definition can be captured in OKBC as non-primitive classes are supported. 

19. For example extended entity relationship (EER) modeling. 
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represents resources and attached attribute/value pairs. Since RDF does not define any 
particular vocabularies for authoring of data, a schema language with appropriate 
primitives is needed. For this purpose the RDF-Schema specification was createdn (cf. 
[8]). RDF-schema is a simple ontology language able to define basic vocabularies 
which covers the simplest parts a of a knowledge model like OKBC (classes, properties, 
domain and range restrictions, instance-of, subclass-of and subproperty-of 
relationships). 

The relationship between OIL and RDF/RDFS is very close because RDF/RDFS was 
meant to capture meaning in the manner of semantic nets. In the same way, as RDF- 
Schema is used to define itself it can be used to define other ontology languages. We 
define a syntax for OIL by giving an RDF-Schema for the core of OIL and proposing 
related RDF-Schemas that could complement this core to cover further aspects. To 
ensure maximal compatibility with existing RDF/RDFS-applications and vocabularies 
the integration of OIL with the resources defined in RDF-Schema has been a main focus 
in designing the RDF-model for OIL (for more details see [28]). In a nutshell, RDFS 
relies on RDF and defines a new name space called RDFS. Some of the OIL primitives 
can directly be expressed in this name space. Others require a refinement of the RDFS 
primitives in an additional OIL name space. 

5 Summary 

In this paper, we sketched out both the syntax and semantics of an ontology exchange 
language called OIL. One of our main motivations while defining this language has 
been to ensure that it has a clear and well defined semantics — an agreed common syntax 
is useless without an agreement as to what it all means. 

The core we have currently defined can be justified from a pragmatic and a theoretical 
point of view. From a pragmatic point of view, OIL covers consensual modeling 
primitives of Frame systems and Description Logics. From a theoretical point of view it 
seems quite natural to us to limit the expressiveness of this version so that subsumption 
is decidable. This defines a well-understood subfragment of first-order logic. However, 
it is important to note that we are open to further discussions that may influence the final 
design of an ontology exchange language. 

We are currently evaluating the use of OIL in the two running 1ST projects: On-to- 
knowledge and Ibrow . In On-to-knowledge, OIL will be extended to become a full- 
fledged environment for knowledge management in large intranets. Unstructured and 
semi-structured data will be annotated automatically and agent-based user interface 
techniques and visualization tools will help users to navigate and query the information 
space. Here On-to-knowledge continues a line of research that was set up with SHOE 
(cf. [33], [27]) and Ontobroker (cf. [15], [17]): using ontologies to model and annotate 
the semantics of information in a machine processable manner. In Ibrow, we are 



20. On-To-Knowledge: Content-driven Knowledge-Management Took through Evolving 
Ontologies, http://www.ontoknowledge.com 

21. IBROW started with a preliminary phase under the 4th European Framework and has been a 
full-fledged Information Society Technologies (1ST) project under the 5th European Framework 
Program since Febmary 2000. http://www.swi.psy.uva.nl/projects/ibrow/home.html 




14 D. Fensel et al. 



currently investigating the usefulness of OIL for software component description, based 
on its integration with UPML (cf [18]). 
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Abstract. Knowledge-based systems have become ubiquitous in recent years. 
Knowledge-base developers need to be able to share and reuse knowledge bases 
that they build. Therefore, interoperability among different knowledge- 
representation systems is essential. The Open Knowledge-Base Connectivity 
protocol (OKBC) is a common query and construction interface for frame-based 
systems that facilitates this interoperability. Protege-2000 is an OKBC- 
compatible knowledge-base-editing environment developed in our laboratory. 
We describe Protege-2000 knowledge model that makes the import and export 
of knowledge bases from and to other knowledge-base servers easy. We discuss 
how the requirements of being a usable and configurable knowledge-acquisition 
tool affected our decisions in the knowledge-model design. Protege-2000 also 
has a flexible metaclass architecture which provides configurable templates for 
new classes in the knowledge base. The use of metaclasses makes Protege-2000 
easily extensible and enables its use with other knowledge models. We demon- 
strate that we can resolve many of the differences between the knowledge mod- 
els of Protege-2000 and Resource Description Framework (RDF) — a system for 
annotating Web pages with knowledge elements — ^by defining a new metaclass 
set. Resolving the differences between the knowledge models in declarative way 
enables easy adaptation of Protege-2000 as an editor for other knowledge- 
representation systems. 



1 The Trade-off between Interoperability and Usability 

In recent years, knowledge sharing and reuse has become one of the primary goals of 
the knowledge-based-systems research community [9]. Enabling interoperability 
among knowledge-representation systems is a crucial step in achieving this goal. The 
Open Knowledge-Base Connectivity (OKBC) protocol [2, 6] facilitates this 
interoperability by providing an application-programming interface (API) that serves 
as a common query and construction interface for frame-based systems. A number of 
OKBC-compatible knowledge-representation systems are currently available includ- 
ing Ontolingua [4], Loom [8], and Protege-2000 [5], which was developed in our 
laboratory. 

Protege-2000 is the latest component-based and platform-independent generation of 
the Protege toolset [5]. Two goals have driven the design and development of Protege- 
2000: (1) being an easy-to-use and configurable knowledge-acquisition tool and (2) 
achieving interoperability with other knowledge-representation systems. We achieve 
the interoperability by making the knowledge model of Protege-2000 compatible with 
OKBC (Section 2). As a result, Protege-2000 users can import ontologies from other 
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OKBC-compatible servers and export their ontologies to other OKBC knowledge 
servers. Protege-2000 uses the freedom allowed by the OBCBC specification to main- 
tain the model of structured knowledge acquisition that was present in all the genera- 
tions of the Protege tools (Section 3) and to achieve the design goal of being a usable 
and extensible tool. 

To function effectively as an access layer for many different knowledge- 
representation systems, it was important for OKBC to have an extremely general 
knowledge model. The set of representational commitments in the OKBC knowledge 
model is minimal and OKBC allows knowledge-representation systems to define their 
own behavior for many aspects of the knowledge model (e.g., default values). Protege- 
2000 restricts the OKBC knowledge model in the following two ways (Section 4): 

1. If implementing a general feature caused significant changes to the way that 

knowledge acquisition is performed in Protege and if OKBC allowed restricting the 

feature and still remain OKBC-compatible, Protege-2000 did that. 

2. If OKBC did not specify the behavior of a knowledge-model component at all, 

Protege-2000 specified the behavior explicitly. 

Protege-2000 also extends some features of the OKBC knowledge model in a way 
that is not prohibited by OKBC. The Protege-2000 metaclass architecture is one such 
extension (Section 5). A metaclass is a template that is used to define new classes in 
an ontology. The use of metaclasses allows us to apply the knowledge-acquisition 
approach that we use to acquire instance data to the ontology-editing process itself. 
Protege-2000 uses metaclasses widely and it implements the internal structure of its 
own knowledge model in a metaclass architecture. 

The metaclass architecture in Protege-2000 along with its component-based ap- 
proach also enables developers to use Protege-2000 as an editor for knowledge- 
representation systems with knowledge models different from that of Protege-2000. 
We have demonstrated this flexibility by defining a knowledge model of Resource 
Description Framework (RDF) [10] as a new metaclass set in Protege-2000. RDF, 
developed by the World-Wide Web consortium, is an emerging standard for defining 
metadata for encoding machine-readable semantics in Web documents. The knowl- 
edge model underlying RDF — RDF Schema [1] — is different from the Protege-2000 
knowledge model. However, it is possible to define the main elements of the RDF 
knowledge model by defining metaclasses that will add RDF-specific features to the 
templates used to create new classes and slots (Section 6). This definition enables the 
use of Protege-2000 as an editor for RDF documents. Our collaborators have imple- 
mented an independent Protege-2000 component that translates the RDF knowledge 
base created in Protege-2000 into standard RDF syntax effectively making Protege- 
2000 an editor for RDF documents. 

2 Protege-2000 Knowledge Model 

The knowledge model of Protege-2000 is frame-based: frames are the principal 
building blocks of a knowledge base. A Protege ontology consists of classes, slots, 
facets, and axioms. Classes are concepts in the domain of discourse. Slots describe 
properties or attributes of classes. Facets describe properties of slots. Axioms specify 
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additional constraints. A Protege-2000 knowledge base includes the ontology and 
individual instances of classes with specific values for slots. The distinction between 
classes and instances is not an absolute one, however, as we will discuss shortly. 

We will use the task of modeling the knowledge about a newspaper-publishing 
company as an example throughout the paper.’ This model must include such notions 
as employees and authors of a newspaper, the newspaper itself, different newspaper 
sections, layout of issues for each day of the week, and so on.^ In this domain, we can 
define a class Newspaper, where we will store the general information of what a 
newspaper is and what properties it may have. The January 1, 2000 issue of the New 
York Times will then be an individual instance of the class Newspaper. 

2.1 Classes and Instances 

Classes in Protege-2000 constitute a taxonomic hierarchy. If a class A is a subclass of 
a class B then every instance of A is also an instance of B. For example, a class repre- 
senting newspaper Editors is a subclass of the Employee class (Fig. 1). Protege- 
2000 visualizes the subclass relation in a tree. Protege supports multiple inheritance: 
one class can have more than one superclass. For example. Editor is a subclass of 
both Employee and Author, since a newspaper editor is both an employee and an 
author of the newspaper. The root of the class hierarchy in Protege-2000 (and in 
OKBC) is the built-in class : THING. 

In Protege-2000, both individuals and classes themselves can be instances of 
classes. A metaclass is a class whose instances are themselves classes (see Section 5). 

2.2 Slots 

Slots in Protege-2000 describe properties of classes and instances, such as contents of 
a newspaper, or the name of an author. A slot itself is a frame. In Protege, as in 
OKBC, slots are first-class objects: Slots are defined independently of any class. 
When a slot is attached to a frame in the user’s ontology, it describes properties of that 
particular frame. For example, we can define a slot name and attach it both to the 
class Newspaper and to the class Author to represent the name of a newspaper and 
the name of an author respectively. When a slot is attached to a frame it can have a 
value. For example, the name slot for a specific issue of a newspaper (instance of the 
Newspaper class) may have a string “New York Times” as the value. 

2.3 Facets 

We can specify constraints on allowed slot values through facets. The constraints 
specified using facets include cardinality of a slot (how many values a slot can have), 
restrictions on the value type of a slot (for example, integer, string, instance of a 
class), minimum and maximum value for a numeric slot, and so on. For example, a 
slot salary can have a type Float and a minimum value of 15,000. When the 



’ You can browse the complete example of the newspaper ontology at the Protege-2000 Web 
site: http://www.smi.stanford.edu/projects/protege/protege-2000/doc/users_guide/index.html 
^ We do not attempt to build a comprehensive model of this domain. 
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slot salary is attached to the class Editor, we can increase the minimum value to 
30,000 . 

2.4 Template and Own Slots 

A slot can be attached to a frame in one of two ways: as a template slot or as an own 
slot. An own slot attached to a frame describes properties of an object represented by 
that frame (an individual or a class). Own slots attached to a class do not get inherited 
to its subclasses or propagated to its instances. Template slots can be attached only to 
class frames. A template slot describes properties of the class instances. A template 
slot attached to a class is inherited by its subclasses. In addition, a template slot on a 
class becomes an own slot on the instances of that class (Fig. 2). 

For example, a slot containing a name of a specific editor — a name slot attached to 
a frame representing that individual instance of the class Editor — is an own slot 
attached to that frame (Fig. 3). All the other slots in the instance frame — salary, 
date hired, and so on — are also own slots attached to this instance. 

Classes can have own slots as well. For example, documentation for a class is 
an own slot attached to that class since it describes the class itself rather than instances 
of that class. If we represented synonyms for each class name, then the synonyms 
slot would also be an own slot for a class: “Source” is a synonym for the class name 
Author in the newspaper context, but it is not a synonym for John — a specific in- 
stance of the class Author. Since both documentation and synonyms in this 
example are own slots for a class, these slots and their values do not get inherited by 




Fig. 1. A representation of an ontology in Protege-2000. The left-hand panel contains the 
class hierarchy. The selected class Editor is a subclass of two classes: Employee and 
Author. The right-hand panel is the form for the class Editor containing the own slots 
for the class and their values and the template slots attached to the class along with their 
value restrictions — facets. 
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Class A 



Template slot 
Allowed-class: C., 



Class B 

Template slot T^ 

Allowed-class: C2 (subclass of C.,) 




Instance I (Individual I) 



Own slot T^ 

Value: 1^ (instance of C.,) 



Instance C (class C) 



Own slot T^ 

Value: I2 (instance of C.,) 



Template slot T3 
Allowed-class: 



A 



J 



Fig. 2 Propagation of template and own slots through the subclass-of and in- 
stance -of relations. 

subclasses. Indeed, synonyms of the class name Author are not related to the syno- 
nyms for the class name Columnist — a subclass of Author. 

Template slots describe properties that an instance of a class shall have. For exam- 
ple, instances of the class Editor — individual editors themselves — have names, 
dates when they were hired, newspaper sections for which they are responsible, and so 
on. The slots name, date hired, and sections are template slots for the class 
Editor (Fig. 1). Every instance of the class Editor has these slots as own slots 
with specific values (Fig. 3). Any subclass of Editor also will inherit these template 
slots. In fact, the class Editor inherited most of its template slots from its super- 
classes: Author and Employee (see Fig. 1). 

To summarize, own slots describe a property of a (class or individual) frame itself 
rather than properties of instances of that frame. Template slots describe properties of 
instances of a class. Own slots do not propagate to either subclasses or instances of the 
frame to which they are attached. Template slots get inherited as template slots to the 
subclasses, and they become own slots for instances. 

Protege-2000 does not allow direct attachment of own slots to classes or instances 
(we explain why in Section 4). An individual instance can acquire own slots only by 
being an instance of a class that has those slots as template slots and a class can ac- 
quire own slots only by being an instance of a metaclass that has those slots as tem- 
plate slots. 




Fig. 3 An instance of a class Editor. All the slots on the form are own slots 
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3 Knowledge-Acquisition Forms 

In Protege-2000, structured data entry allows users to enter information about in- 
stances quickly and easily and to verify the entered information directly. Protege-2000 
enables structured data entry by using knowledge-acquisition forms to acquire in- 
stances information. The form-based interface is one of the central user-interface 
metaphors in Protege. When a user defines a class and attaches template slots to it, 
Protege automatically generates a form to acquire instances of that class. The slots for 
the class, their cardinality and value type determine the default layout and the content 
of the form. For example, Protege-2000 uses a text field as a default way to display 
and acquire a value of a single-cardinality slot of type string. It uses a pull-down 
menu for a slot whose values are limited to a set of symbols. It represents a boolean 
slot with a checkbox. It uses a list for slots that have multiple values. 

Users can customize the standard form that Protege-2000 automatically generates 
for each class to suit the requirements of the specific class better. Customization in- 
cludes changing the layout of the form components by moving the “important” infor- 
mation to the top of the form, changing labels for the form fields, and choosing differ- 
ent ways of displaying and acquiring slot values. For example, we can use a text field 
(with the appropriate validation) to acquire an integer value or we can use a slider to 
set the value instead (Fig. 4). The component-based architecture of Protege-2000 en- 
ables developers to write their own domain-specific and task-specific components to 
acquire and display slot values. 

The current knowledge-acquisition process in Protege-2000 therefore consists of 
three steps: (1) define a class and its template slots; (2) lay out the form that will be 
used to acquire instances of that class; (3) acquire instance of the class. Therefore, 
there is a form associated with each class and this form is used to acquire instances of 




Fig. 4. Customizing the form for class Editor. We choose to use a slider to acquire the 
numeric value for the salary slot instead of a text field used in the form in Fig. 1 
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that class. This user-interface approach resulted in some restrictions in our support of 
the OKBC knowledge model. We discuss these restrictions in the next section. 

4 OKBC and Protege-2000 Knowledge Models 

Protege-2000 uses the OKBC knowledge model [2] as the basis for its own knowledge 
model. The main goal of the OKBC developers was to ensure maximum generality 
and interoperability among knowledge-representation systems. Therefore the OKBC 
knowledge model makes minimal knowledge-representation commitments and it is 
extremely general. OKBC attempts to incorporate all the features of the basic ap- 
proaches to frame-based systems. To allow maximum flexibility, when incompatibil- 
ity between two features arose, the OKBC designers often allowed both features with- 
out requiring the OKBC-compatible systems to implement either of them.^ In some 
cases, OKBC did not specify the behavior at all leaving the implementation up to the 
knowledge-representation systems completely. This approach — allowing as many 
features as possible, requiring as few features as possible, and leaving some features 
underspecified — is perhaps the best approach for a common-access protocol, but de- 
signers of individual systems must make some design choices that restrict this gener- 
ality. 

The Protege-2000 knowledge model is completely compatible with OKBC: Protege 
implements everything that the OKBC knowledge model requires and everything in 
the Protege-2000 knowledge model is logically consistent with OKBC. For the fea- 
tures where OKBC allows flexibility, Protege-2000 preserves as much of the OKBC 
generality as possible and restricts the OKBC model only when the current Protege 
user-interface paradigm requires it. Table 1 summarizes differences between the Pro- 
tege-2000 and the OKBC knowledge model. Table 1 does not include all the differ- 
ences between the knowledge models of Protege-2000 and OKBC. The exhaustive 
discussion of features where Protege-2000 knowledge model diverges from the OKBC 
one, such as own facets and template-slot values, is beyond the scope of this paper. 

We made the design choices in Protege-2000 to enable optimal knowledge acquisi- 
tions. As with any evolving system, the decisions may change if we no longer believe 
that they are justified by the knowledge-acquisition requirements. 

The first for items in Table 1 result from the Protege approach to modeling and 
knowledge acquisition: Protege generates a knowledge-acquisition interface based on 
the users’ specification of the objects that they need to acquire. This specification 
includes defining a class of objects to acquire, having Protege generate a knowledge- 
acquisition form based on the class definition, and, if necessary, custom-tailoring the 
form to acquire that class of objects (Section 3). This approach to knowledge acquisi- 
tion requires that there is always a way to specify and to custom-tailor a form for ac- 
quiring information for any instance. The first four items in Table 1 ensure that there 
is indeed a class form associated with every instance. If a frame is an instance of more 
than one class, there is no single place where the form can be laid out, since different 
own slots for the instance come from different classes. Similarly, if an own slot is 



^ The OKBC protocol enables the knowledge-based systems to specify their design choices. 
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attached directly to an instance and it does not come from a template slot, there is no 
place where the user can customize how the values of the slot should be acquired. The 
same problem is true if a frame is not an instance of any class: all the own slots need 
to be attached to it directly and there is no place where the form can be laid out before 
the slot values for the instance are acquired. 

Currently, the Protege-2000 user interface is centered around frames and forms to 
acquire values for slots. Therefore only primitive data types — numbers, strings, sym- 
bols, and so on — do not have to be represented as frames. All the user-defined entities 
are frames. This requirement is less general than the OKBC approach where objects 
do not have to be frames. For example, a set {1,2, 3, 4} can be a class. 

The sets of classes, slots, and facets are disjoint in Protege-2000. An object can be 
either a class, or a slot, or a facet. Protege imposes this requirement because the three 
types of frames play inherently different roles in the knowledge acquisition process. In 
summary, we used the flexibility that OKBC allows to restrict some of the features of 
the extremely general knowledge model and thereby maintain the uniform knowledge- 
acquisition interface. There are aspects of a knowledge-representation system for 
which OKBC allows alternative behaviors or does not specify the behavior at all. We 
utilized the latter flexibility to implement the Protege metaclass architecture described 
in the next section. 

5 Metaclasses 

The Protege-2000 metaclass architecture enables us to extend the knowledge- 
acquisition approach that we use to acquire instance data to the ontology-editing proc- 
ess itself. We can customize and lay out the forms for specifying classes and slots in 
exactly the same way that we customize and lay out forms for acquiring instances 
(Section 3). The metaclass architecture in Protege-2000 also enables developers to use 
Protege-2000 as an editor for knowledge-representation systems with knowledge 
models different from that of Protege-2000. For example, in Section 6 we describe an 
example implementation of an editor for Resource Description Framework schema 
and instance data in Protege-2000. The Protege-2000 metaclass architecture is mod- 
eled after the metaobject protocol [7] in the Common Lisp Object System. 



Table 1. Summary of differences between the knowledge models of OKBC and Protege-2000 
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A metadass is a class whose instances are themselves classes. Every frame in Pro- 
tege-2000 is an instance of a class (see Table 1). Since classes are also frames, every 
Protege-2000 class is an instance of another class. Therefore, every class has a dual 
identity: It is a subdass of a class in the class hierarchy — its superclass, — and it is an 
instance of another class — its metaclass. In this section, we will describe how meta- 
classes work in Protege-2000, give examples of how metaclasses can be used in 
knowledge modeling and describe the metaclass architecture of the Protege-2000 
knowledge model itself 

5.1 What is a Metaclass 

Metaclass is a template for classes that are its instances. A metaclass describes how a 
class that instantiates this template will look: namely, which own slots it will have and 
what are the constraints for the values of these slots. Similarly, a traditional class de- 
scribes how instances of that class will look: which own slots the instances will have 
and what are the constraints for the values of these slots. 

Own slots for a class — the slots that the class acquires from its metaclass — describe 
the properties of the class itself and not of its instances. For example, a class’s docu- 
mentation is a free-form description of the class. It describes the class itself and 
not the class’ subclasses or instances. 

In Protege (and in OKBC) all metaclasses are subclasses of the system class 
: CLASS. By default, each class in Protege is an instance of the : STANDARD -CLASS 
metaclass, which is a subclass of : CLASS. The : STANDARD -CLASS metaclass has 
template slots to store a class’s name, documentation, a list of template slots, a list of 
constraints, and so on (Fig. 7). These slots then become own slots for each of the 
newly created classes — instances of : STANDARD -CLASS. We will discuss 
: STANDARD -CLASS in more detail in Section 5.3. The form that Protege uses to 
acquire the class information (for example, the form on the right-hand side in Fig. 1) is 
in fact the knowledge-acquisition form that corresponds to the : STANDARD -CLASS 
class. Users can customize this form in exactly the same manner as they customize 
forms for other classes. 

Protege-2000 allows users to define their own metaclasses and to define new 
classes as instances of these user-defined metaclasses. They can then customize the 
forms to acquire instances of these metaclasses, which are new classes in the ontology, 
effectively creating new ontology editors [3]. 

5.2 User-Defined Metaclasses 

Consider the earlier example of defining a newspaper ontology. Suppose we wanted to 
record the recommended minimum and maximum salary for different employee posi- 
tions as well as whether or not a particular position is at the management level. For 
example, the recommended minimum salary for an editor is $30,000 and the recom- 
mended maximum salary is $60,000. An editor is a management position. Since the 
two numbers are only the recommended minimum and maximum, we cannot encode 
them as the minimum and maximum constraints for the salary slot: our model 
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should allow a very good editor to earn more than $60,000. Also, we consider all edi- 
tors to be managers and we should not have to specify this fact for each new instance 
of the Editor class. These three slots — the recommended minimum and maximum 
salary and whether or not the position is a management position — are in fact own slots 
for the class Editor: the values of these slots define properties of the Editor class, 
but not the properties of their corresponding instances. 

We will use metaclasses to implement this model. We define an Employee 
metaclass class which we will then use as a template for the class Employee and 
all of its subclasses. Protege-2000 requires that all metaclasses be subclasses of the 
system class : CLASS. In practice, most metaclasses are subclasses of : STANDARD- 
CLASS, since all the metaclasses usually include the slots defined in : STANDARD- 
CLASS (see Section 5.1). We create additional template slots for the Employee 
metaclass (Fig. 5): the minimum recommended salary and maximum 
recommended salary slots have the value type Integer and cardinality Sin- 
gle; the management position slot has the value type Boolean. 

We define the Employee class and its subclasses as instances of the Employee 
metaclass. These classes then have the three new slots as their own slots. The 
Editor class in Fig. 1 was an instance of the : STANDARD -CLASS metaclass and 
did not have these domain-specific own slots. Fig. 6 shows the definition of the class 
Editor as an instance of Employee metaclass. Before defining the Editor 
class, we laid out the form for the Employee metaclass class in a manner simi- 
lar to the one demonstrated in Fig. 4. Protege-2000 uses this form to acquire instances 
of the Employee metaclass class such as the Editor class. 




Fig. 5 Definition of the class Employee metaclass. The template slots defined here 
will become own slots for classes that are instances of this metaclass 
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5.3 Protege-2000 Built-in Metaclass Architecture 

Protege-2000 uses the metaclass mechanism to implement its own internal class 
structure. Metaclasses define the representation of all the frames in the system — 
classes, slots, facets, and individuals. All the information about a class, from its name 
and documentation to a list of its template slots and superclasses, is stored in its own 
slots. In other words. Protege uses its own class structure to store the information 
about itself. The users of Protege-2000 do not need to see this internal information 
(and very few users do indeed see it) unless they decide to explore the ontology 
describing the Protege-2000 knowledge model. The three system classes — : CLASS, 

: SLOT, : FACET — serve as types for all the Protege-2000 classes, slots, and facets 
respectively. These classes do not have any template slots attached to them. This 
feature allows Protege-2000 developers to implement their own knowledge models in 
Protege-2000 without making the same knowledge-model assumptions that Protege- 
2000 does. The Protege-2000 knowledge model itself is implemented using the three 
standard subclasses of these classes: : STANDARD-CLASS, : STANDARD -SLOT, and 
: STANDARD- FACET. These three classes have the template slots that define the 
structure of their instances — the Protege-2000 classes, slots, and facets respectively. 

: STANDARD -CLASS defines the default metaclass for Protege-2000 classes. 

• Template slots of : STANDARD -CLASS (Fig. 7) define the standard own slots for 
classes in Protege-2000. The slots store the class name, documentation, direct sub- 
classes, direct superclasses, and direct template slots for the class. Usually, all the 
user-defined metaclasses will be subclasses of : STANDARD -CLASS. The 
: STANDARD -CLASS is an instance of itself and therefore has the same sets of 
slots attached to it twice: once as own slots with values and once as template slots 
with value-type restrictions in the form of facets. 




Fig. 6 The definition of the Editor class as an instance of the Employee metaclass. The 
definition has the additional own slots with the corresponding values. The Editor class in 
Fig. 1 was an instance of : STANDARD -CLASS and did not have these own slots. 
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Fig. 7 Definition of the : STANDARD-CLASS metaclass. Protege-2000 uses the slots at- 
tached to this class to store the information about all its classes 

• : STANDARD -SLOT defines the default metaslot in Protege-2000. Template slots 
of : STANDARD -SLOT such as : SLOT-DEFAULTS, : SLOT-VALUE-TYPE and 
SO on define the standard own slots for slot frames in Protege-2000. These slots 
store the slot name, its documentation, value type, default values, cardinality, and 
so on. User-defined metaslots are subclasses of : STANDARD -SLOT. 

• : STANDARD -FACET defines the class to which all the built-in and user-defined 
facets belong. Currently there are no required slots for facets. 

We can use the Protege-2000 form mechanism to customize the forms for acquiring 
data for instances of these metaclasses. For example, if a customized version of the 
system does not need to have the constraint slot on the class form, the user can simply 
customize the form for : STANDARD -CLASS to remove the elements acquiring con- 
straints from the form. 

To summarize, the metaclass architecture in Protege-2000 enables users to adapt 
and change the system to suit the requirements of their domain and task. This adapta- 
tion can be performed in two ways: (1) custom-tailoring the knowledge-acquisition 
forms for class definitions and (2) changing the knowledge model by defining a new 
metaclass architecture. 

In the next section we demonstrate how we can use the Protege-2000 metaclass ar- 
chitecture to implement a different knowledge model in Protege-2000 — ^that of RDF. 



6 Adapting to a Different Knowledge Model — RDF 

The combination of (1) the metaclass architecture, (2) the ability to define specialized 
user-interface components to display and acquire slot values, and (3) the ability to 
implement additional persistence layers as components in Protege-2000 allows Pro- 
tege-2000 users to adapt the tool to create and edit knowledge bases with knowledge 
models that are different from the Protege-2000 knowledge model. 

With our collaborators, we have recently adapted Protege-2000 to become an editor 
for Resource Description Framework (RDF) Schema and instance data. RDF is an 
evolving knowledge-representation standard being defined by the WWW Consortium 
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[10]. The main goal for RDF is to make Web-based pages not only human-readable 
but also machine-readable enabling computer agents to use the information. Currently, 
HTML enables Web-site developers to encode how the document is going to appear 
on the page. RDF takes the representation further, allowing semantics to be encoded 
as well. For example, two Web sites may describe the same movie: the Internet Movie 
Database has a list of all the characters, awards, technical details, and so on. Ama- 
zon.com has the information on purchasing the videotape. If the two sites represent the 
information formally and use a shared ontology to do so, an agent can link the two 
databases and can answer requests that require the knowledge of both. The RDF 
Schema specification defines the knowledge model that will be used to express on- 
tologies in RDF [1]. 

Adapting Protege-2000 to become an editor for RDF Schema and instance data re- 
quires bridging the gap between the two knowledge models. We now describe what 
the differences are and how we can resolve many of the differences by defining spe- 
cialized classes and metaclasses in Protege-2000. We then discuss which differences 
we cannot resolve declaratively and describe how they can be solved as part of the 
RDF persistence layer — a Protege-2000 component that translates between the Pro- 
tege-2000 internal representation of classes and the RDF serialization format. 

6.1 Summary of the RDF Knowledge Model 

RDF is a model for describing resources. Anything can be a resource. An RDF docu- 
ment describes resources and relations among resources. An RDF Schema defines 
what classes of resources exist, how resources are related to one another and what 
restrictions on those relations exist. 

In RDF, classes of concepts constitute a hierarchy with multiple inheritance. 
Classes have instances and a resource can be an instance of more than class. Re- 
sources have properties associated with them. Properties describe attributes of a re- 
source or a relation of a resource to another resource. A property is represented as a 
predicate-subject-object triple: predicate is the property, object and subject are re- 
sources related by the property. For example, a statement “John is a father of Alice” 
can be represent as a triple consisting of the predicate father, subject John, and 
object Alice. A property can be a specialization of another property. The RDF 
schema defines domain of a property — resources that can be subjects of the prop- 
erty — and range of a property — resources that can be objects of the property. For 
example, the property father may have a class Person both as its domain and as 
its range. 

RDF defines a set of core properties. For example, the rdf s : seeAlso property 
specifies another resource containing information about the subject resource and the 
rdf s : isDef inedBy property indicates the resource defining the subject resource. 

Therefore, a class (in the sense of frame-based languages) is defined by a resource 
and all the properties describing the resource (all the properties where the resource is 
the domain). The following are the core classes in RDF: 

• rdf s : Resource: the class containing all resources — the superclass for all RDF 

classes 
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• rdf s : Class: the class containing all classes as its instances — the metaclass for 
all RDF classes 

• rdf : Property: the class containing all properties — the metaslot for all RDF 
properties 

6.2 Core RDF Classes and Metaclasses in Protege-2000 

Both RDF and Protege-2000 are based on a frame-based paradigm and their knowl- 
edge models have a lot in common. The notion of classes is the same. Classes are 
organized in a taxonomic hierarchy in both cases. Classes can have instances. Proper- 
ties in RDF are slots in Protege. Both properties and slots are first-class objects de- 
scribing attributes of classes and instances and relations among them. 

We start by defining in Protege-2000 the core RDF classes described in the Section 
6.1 (Fig. 8). The Protege-2000 class rdf s : Resource is the root of the hierarchy of 
classes defined in an RDF schema. This class has three template slots: resource 
uri to store a Uniform Resource Identifier and the core properties rdf s : seeAlso 
and rdf s : isDef inedBy, which are required by each resource. All the classes that 
are subclasses of rdf s : Resource inherit these slots. 

The class rdf s : Class is a default metaclass for all the newly defined classes in 
the RDF project. It is also a subclass of rdf s : Resource. Therefore, 
rdf s : Class inherits the three template slots attached to rdf s : Resource. These 
template slots become own slots for instances of rdf s : Class — all the classes in the 
RDF project. The rdf s : Resource and rdf s : Class are themselves instances of 
rdf s : Class and therefore they have these standard slots as their own slots as well. 

The class rdf : Property is a default metaslot in the RDF project. It is the tem- 
plate for all newly defined slots. The metaslot rdf : Property is a subclass of both 
rdf s : Resource and : STANDARD -SLOT. As a result all slots — ^properties — have 
these own slots: resource uri, rdf s : seeAlso, and rdf s : isDef inedBy. 




Fig. 8 The RDF project: definition of the rdf s : Resource class. The template slots 
attached to this class will propagate to all the classes and instances in the project. 
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Table 2. Summary of differences between the knowledge models of Protege-2000 and RDF 



1 

2 



3 



Protege-2000 

A frame can be an instance of only one 
class 

A value of a slot can be a value of a 
primitive type or an instance of a class. 
There can be one or more classes that 
constrain the value 

A slot in an individual instance and cannot 
be a subclass of another slot 



RDF and RDF Schema 

A resource can be an instance of multi- 
ple classes 

The range of a property is a single class 
which constraints the objects of the property 
to instances of that class 

A property can be a specialization of an- 
other property 



6.3 Differences between the Protege-2000 and RDF Knowledge Models 

Defining the RDF metaclass structure cannot resolve all the differences between the 
Protege-2000 and RDF knowledge models. The implementation of the RDF persis- 
tence layer — a Protege-2000 component that translates the knowledge base betwee the 
internal Protege-2000 representation and RDF documents — can resolve the differences 
between the knowledge models that could not be resolved by defining the metaclass 
structure. The RDF persistence layer enables the direct import and export of RDF 
documents making Protege-2000 an editor for RDF documents. Our collaborators 
have implemented one such component. 

Table 2 presents some of the differences between the Protege-2000 and the RDF 
knowledge models that the persistence layer must resolve. As in OKBC, resources in 
RDF can be instances of more than one class. In Protege-2000 each instance is a 
member of only one class. However, multiple inheritance enables Protege-2000 to 
simulate the multi-class membership. If an imported RDF schema has an instance I 
that belongs to several classes, Ci, . . ., Cn, the persistence layer can create a new class 
C that is a subclass of all of Ci, . . ., Cn. The instance I will then be an instance of the 
class C and, by inheritance, it will be an instance of all the original classes Ci, . . ., Cn- 

In RDF Schema, the range of a property is constrained to a single class. That is, the 
objects of a property must be instances of that single class. In Protege-2000, slot range 
can be a primitive data type, can be constrained to instances of several classes 
(“allowed classes” for the slot), or can be constrained to subclasses of several classes 
(“allowed parents” for the slot). If a Protege-2000 slot has multiple allowed classes, 
the RDF persistence layer can create a new class that is a superclass of all of the in- 
tended allowed classes and use the new class as the range for the RDF property. 

The RDF Schema allows specializing properties. For example, the father prop- 
erty is a specialization of the more general parent property: If John is a father of 
Alice, then John is also a parent of Alice. In Protege-2000, all slots are individual 
instances and therefore cannot form a subclass-superclass hierarchy. If a domain 
model requires a hierarchy of properties, the properties can be reified to become 
regular classes in the class hierarchy. 

To summarize, we extended the Protege-2000 built-in metaclass architecture to im- 
plement the structure of RDF Schema declaratively and the RDF persistence layer can 
use the knowledge structures to hide or repair other differences programmatically. 
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7 Conclusions 

We have presented the knowledge model of Protege-2000 — an ontology-editing and 
knowledge-acquisition environment. The OKBC-compatibility of the knowledge 
model enables the interoperability between Protege-2000 and other OKBC-compatible 
systems. We have discussed how the knowledge model was affected by the require- 
ments for structured knowledge acquisition. The Protege-2000 metaclass architecture 
enables elegant and powerful knowledge modeling as well as allows us to implement 
the internal structure of Protege-2000 explicitly in the ontology. We have described 
how Protege-2000 uses its own metaclasses to describe itself. The flexibility of the 
knowledge model and the component architecture of Protege-2000 make it easy to 
adapt the tool to work as an editor for other knowledge-representation systems. We 
demonstrated how Protege-2000 can be adapted to become an editor for RDF. 
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Abstract. This article describes a case study in which Protege-2000 was used to 
build a tool for constructing CommonKADS knowledge models. The case study 
tries to capitalize on the strong points of both approaches in the tool-support and 
modeling areas. We specify the CommonKADS knowledge model as an ontology 
in the Protege specification formalism, and define a number of visualizations 
for the resulting types. The study shows that this type of usage of Protege-2000 
as a “metaCASE” tool is to a large extent feasible. In particular, the flexible 
class/instance distinction in Protege is a feature that is needed for undertaking 
such a metamodeling exercise. The case study revealed a number of problems, 
such as the representation of rule types. The study also led to a set of new tool 
requirements, such as extended expressivity of the Protege forms. Finally, this 
experience shows how the concrete, operational approach of Protege and the highly 
methodological approach of CommonKADS can be combined successfully to 
provide the middle-ground tool that reduces the gap between a conceptual model 
and a usable knowledge model. 



1 Introduction and Approach 

Knowledge engineering has matured and KE techniques are used increasingly not just 
for knowledge-system development but also for knowledge analysis and structuring in 
knowledge management in general. However, the availability of adequate tool support is 
crucial for a wider adoption of these techniques. In this paper we describe a case study in 
which we used the Protege-2000 tool to build a “knowledge-model editor” for Common- 
KADS. This editor should support analysts and (to a limited extent) domain specialists 
in modeling a knowledge-intensive task using the CommonKADS knowledge-modeling 
framework [11]. The aim was to create an editor that adheres as much as possible to the 
distinctions made in the CommonKADS knowledge model. 

This case study tries to capitalize on the strong points of both approaches. Tradi- 
tionally, Protege has put an emphasis on providing configurable and usable knowledge- 
engineering tools [10]. In CommonKADS the main focus of attention has always been 
on the modeling side, more or less assuming that support tools would become available 
in due time. This case study was triggered by the observation that the Protege-2000 tool 
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is capable of supporting metamodeling. This recent addition to Protege extends its scope 
to creating customized editors for knowledge representation systems with different kno- 
wledge models [5]. Another interesting feature of Protege-2000 is the possibility to save 
the results as RDF [8]. Finally, the authors thought it would be a sign of maturity of 
the knowledge-engineering field if two leading methodologies could be linked in this 
fashion. 



Tool requirements. In this case study we look at the usability of Protege-2000 from 
the perspective of three different types of users: 

1. The tool builder: the person constructing the knowledge-model editor. 

2. The knowledge engineer: the person using the editor to create and maintain a kno- 
wledge model. Also, the knowledge engineer should be able to define a domain- 
knowledge editor to be used by the domain specialist. 

3 . The domain specialist: the person editing and updating the actual domain knowledge 
of the application. 

These three types of users have different requirements. For the tool builder the main 
requirement is expressivity: can she define the required modeling constructs and visua- 
lizations without losing information or clarity? The question whether the interface is 
easy to use is less important for this type of user, as a high level of expertise in this area 
is required anyway. The knowledge engineer needs a tool that enables a convenient and 
consistent environment for defining a knowledge model. For her it is important that there 
be no specification redundancy and that consistency and completeness checks for model 
verification be available. Also, she should be able to include and adapt predefined mo- 
del parts, such as the catalog of CommonKADS task templates. The domain specialist 
will especially be interested in a simple and intuitive interface for updating knowledge 
bases. Early Protege research has shown that this requires the use of a domain-specific 
vocabulary in the user interface [9]. 

Of course, these requirements are related, as the tool created by the tool builder has a 
strong influence on the functionality offered to the knowledge engineer. The same holds 
for the domain specialist, who has to use the knowledge-elicitation interface defined 
by the knowledge engineer. Still, we view these three users as useful perspectives for 
evaluating the usability of Protege-2000. 



Related work. Over the years, a number of tools have been developed for knowledge 
modeling with CommonKADS. An early example is the Shelley workbench [1]. PC- 
PACK^ is a contemporary tool with similar aims. PC-PACK focuses on the early phases of 
knowledge acquisition. It provides functionality for annotating and structuring expertise 
data such as domain texts, interviews, and self reports. Examples of the use of PC- 
PACK can be found in various publications [11,13]. Although PC-PACK offers some 
support for knowledge-model specification through the GDM grammar [ 1 4] , the tool can 
best be seen as complementary to a knowledge model editor. The main area in which 

’ http : //www. epistemics . co.uk/products/pcpack/ 
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functionality overlaps concerns the interface for the domain specialist. WebCokace^ is 
an interactive web editor for CommonKADS knowledge models [4], It uses an earlier 
version of the CommonKADS CML language to represent knowledge models. The tool 
is targeted at the knowledge engineer and provides facilities for reusing model elements 
from catalogs, such as existing task templates and ontologies. KADS-22^ is also targeted 
at the knowledge engineer and supports the knowledge-model editing using the CML 
version used in the CommonKADS textbook [11]. The tool includes graphical editors 
and can produce “pretty-prints” of the knowledge model, for example in HTML format. 

CASE tools also need to be compared with “low-level” tools, in particular dedicated 
drawing tools. A CASE tool needs to have a marked advantage in functionality for users 
to prefer it above such baseline tools. A good example of a baseline tool is ModelDraw"^, 
developed by Wielemaker. In an evaluation study one would typically want to compare 
a “heavy” CASE tool with such a light-weight drawing tool. 



Paper overview. In Sec. 2 we briefly summarize the main features of Protege-2000 and 
of CommonKADS. Sec. 3 reports on the tool construction process and shows examples 
of usage of the tool. In Sec. 4 we discuss the experiences gathered during this case 
study, taking also the different user perspectives into account. Throughout this paper we 
use examples from an assessment application. This application is concerned with the 
problem of assessing whether people who applied for a certain (rental) residence conform 
to the criteria set out for this residence. A full knowledge model of this application can 
be found in the CommonKADS textbook [11, Ch. 10]. The code of the tool including 
the example can be downloaded from the Protege-2000 website.^ 

2 Background 

2.1 Protege-2000 

Protege-2000 is the latest incarnation of the series of tools developed for many years by 
researchers at SMI to provide efficient support in knowledge modeling and knowledge 
acquisition [7]. Protege-2000 is platform-independent and offers a component-based 
architecture, which is extensible through its API. Protege was recently adapted to support 
the creation and editing of RDF Schema ontologies and the acquisition of RDF instance 
data (see [5] for more details). In the rest of this article we use the shorthand “Protege” 
to refer to Protege-2000. 



Frame-based knowledge model. Protege is a frame-based environment for knowledge- 
based system development. Its knowledge model has been re-factored to meet the requi- 
rements of the recent OKBC standard [3]. An ontology in Protege consists of classes, 
slots, facets and axioms [5]: 

^ http: //www-sop . inria.fr/acacia/Cokace/ index-eng.html 
^ http: //www. swi .psy.uva.nl/projects/kads22/index.html 
^ http : //www . commonkads . uva . nl/, see the tools section 
^ http: //smi . Stanford. edu/projects/protege/ 
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- Class frames specify domain concepts and are organized in a subsumption hierarchy, 
that allows for multiple inheritance. Classes are templates for individual instance 
frames. 

- Slots are special frames that can be attached to classes to define their attributes, 
with specific value type restrictions. Own slots define intrinsic properties of class 
or individual instance frames. Template slots are attached to class frames to define 
attributes of their instances, which in turn define specific values for slots. Slots in 
Protege are first-class objects. They can be specified both globally for the ontology 
and locally as attached to classes, where their properties are overridden. 

- Facets are properties of slots, which specify constraints on their allowed values. 
Examples are the cardinality of a slot value, its type (primitive, such as string or 
integer, or complex, such as instance of a class), range and default values, etc. 

- Axioms are additional constraints that can be defined on frames, for example to 
link the values of a group of template slots attached to a class. As a very recent 
addition to Protege, a constraint language enables developers to represent constraints 
throughout an ontology as sentences expressed in KIF-based [6] predicate logic. 
Protege defines a set of built-in predicates and functions that can be used to express 
constraints. Protege also provides functionality to evaluate the constraints and check 
that the individual instances in a knowledge base conform to those constraints. 
Examples of constraints are given in Sec. 3.3. 



Configurable forms for knowledge acquisition. Protege-2000 perpetuates the support 
for structured and customizable knowledge entry that has always been fundamental to 
the Protege tools. It achieves that goal by providing a configurable user interface for all 
steps in the process of modeling and acquiring domain- and task-specific knowledge. 
The graphical user interface of Protege allows users to define and visualize classes and 
their slots, to customize a corresponding set of forms for acquiring instances of the 
classes, and to acquire instances themselves. 

The central metaphor for knowledge acquisition in Protege is the notion of a form 
composed of a set of graphical entry fields (“widgets”). A form is attached to a class to 
display and acquire its instances. Specific widgets facilitate and locally verify the entry 
of slot values on instances. Based on the specification of the classes in an ontology, such 
as the value-type restrictions on their template slots. Protege automatically generates a 
form for each class, with a default layout and set of widgets (text fields for string slots, 
pull-down menus for enumerated symbolic slots, etc.). Tool builders and knowledge 
engineers can customize the generated forms to meet domain-specific requirements on 
knowledge entry and checking. They can rearrange the layout and configure the widget 
components on the forms, or provide their own pluggable widget. 

A special kind of knowledge acquisition metaphor that Protege offers is the notion 
of a diagram, which provides a means for the synthetic display and acquisition of com- 
plex structures defined by a set of related classes in the ontology. Protege’s support for 
diagrams comes with a special-purpose ontology of metaclasses and classes represen- 
ting diagrammatic components, that the user extends to create domain-specific diagram 
templates. The user defines the nodes of the diagram, that refer to domain classes in the 
ontology and the types of connectors that can link nodes together. Forms are generated 
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for each diagram construct, that not only take care of graphical layout and navigation but 
also handle consistency and partially automatic filling of the instances and slot values 
being acquired through this metaphor. The user is also able to fill-in additional details 
of instances by zooming into the nodes and connectors. 



Flexible class/instance distinction. Protege also provides a flexible class/instance di- 
stinction based on the notion of metaclasses. A metaclass is a class whose instances are 
classes themselves. Thus, metaclasses are templates to create new classes and slots in 
an ontology. They define template slots that are propagated to their instance classes as 
own slots. Examples are the role and documentation own slots on standard classes. 

The metaclass mechanism is described in detail elsewhere [5]. The mechanism im- 
plements the internal structure of the Protege knowledge model itself with a set of 
built-in metaclasses for classes, slots and facets. The metaclass mechanism also enables 
developers to tailor the underlying knowledge model of their ontology, by defining their 
own domain- or task-specific metaclasses. Forms for the metaclasses can be customized 
and instances (new classes and slots in the ontology) can be acquired, similarly to tra- 
ditional classes and instances. Therefore, this approach extends the scope of modeling 
possibilities to metamodeling: Developers can use Protege as an editor for knowledge 
representation systems with different knowledge models. 

The case study that we describe in this paper can be seen as using Protege to build 
a specific editor for CommonKADS knowledge bases. As we show in the next section, 
we made heavily use of the metamodeling constructs offered by Protege to define the 
CommonKADS knowledge model. 

2.2 CommonKADS 

Details about the CommonKADS approach can be found in the recent CommonKADS 
textbook [11]. CommonKADS is centered around a so-called “model suite”, which takes 
different perspectives on a knowledge-intensive task. The central model is the knowledge 
model. The use of CommonKADS in this case study is limited to this model. A synopsis 
of the main constructs in a knowledge model can be found in Table. 1 . 

Most constructs are well known from previous CommonKADS publications, e.g. 
[12]. A relatively recent addition is the notion of rule type in the domain knowledge. 
A rule type is used to model a set of rules that share a similar structure. For example, 
in the assessment application we distinguish three rule types: (1) abstraction rules that 
are used to abstract case values (e.g., the age category of an applicant can be derived 
from the age), (2) requirements describing the way in which case values determine truth 
or falsehood of an assessment criterion such as RentFitsIncome, and (3) decision rules 
that link a boolean combination of criterion values to a particular decision (eligible or 
not). Although intuitively the notion of rule type can be easily understood, from a formal 
point of view it is in fact quite complex. We will see later on that the rule type was the 
“hardest nut to crack” when constructing the tool. 
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Category 


Construct 


Description 


Task 

knowledge 


task 


a problem statement of wbat needs to be achieved; specifies 
also input and output 


task method 


a way to achieve a task by decomposing it into subtasks, 
inferences and transfer functions; also defines a control 
regimen over the decomposition 


Inference 

knowledge 


inference 


a primitive reasoning function that uses a part of the domain 
knowledge to achieve a basic problem-solving step 


dynamic role 


input or output of an inference; signifies a place holder and an 
abstract name for domain objects “playing” the role 


static role 


the static knowledge used by an inference, also defined as a 
placeholder for domain objects (e.g., a rule set) 


transfer 

function 


a primitive function needed to that interact with the outside 
world 


Domain 

knowledge 


domain schema 


a set of domain-type definitions; a domain schema can be 
imported into other schemata 


concept 


a group of “things’Vith shared features; cf “object class” or 
“entity” 


relation 


a set of tuples that relate “things”to each other; cf. 
“association”, ER-type relationship 


rule type 


expressions about concepts/relations in an 
antecedent/consequent form 


knowledge base 


a set of domain-type instances (usually rule instances) that can 
be used as static knowledge by one or more inferences 



Table 1. Constructs in tbe CommonKADS knowledge model 



3 Constructing the Protege-CK Tool 

3.1 Architectural Considerations 

In order to build a tool for specifying a CommonKADS knowledge model we need to 
define the knowledge-model constructs as classes and slots in Protege. For example, a 
task can be represented as a class with slots pointing to the input and output roles, the 
method that realizes it, etc. Actual tasks will then be instances of task. The same can 
be done for all task and inference constructs listed in Table. 1, i.e., inferences, roles, 
methods and transfer functions. 

However, this approach presents a problem when we come to the domain types. We 
have three abstraction levels here which we like to represent: 

1. Domain-modeling constructs: concept, relation, rule type. 

2. Domain-specific types: concept applicant, rule type abstraction-rule. 

3. Domain-specific instances: a particular applicant or a particular abstraction rule. 

This problem is typical of metamodeling in general. What seems to be an instance from 
one level, behaves as a class at a lower level. To handle this we can make use of the 
flexible class/instance distinction made by Protege. We can define a class as being an 
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instance of a custom metaclass. The resulting class can both be used as an instance (filling 
in slot values for the slots defined on the metaclass) and as a class (defining template 
slots for its own instances as well as constraints that should hold). Note that this use of 
metaclasses is different from approaches in which a metaclass is nothing more than an 
abstract superclass. 

By way of the metaclass architecture we were able to model the three-level ap- 
proach of the CommonKADS knowledge model. For example, we defined a domain- 
type metaclass as a template for all domain type classes with an additional template slot 
rolesPlayed to denote the knowledge role of its instances in the domain. We represented 
domain-modeling constructs as instance classes of DomainTypeMetaClass, with a root 
class DomainType. We then modeled domain-specific types as subclasses of the domain 
modeling classes (thus also instances of DomainTypeMetaClass) with specific values for 
their rolesPlayed slot. Finally, domain-specific individuals can be acquired as instances 
of the domain-specific classes. In Sec. 3.3 this approach is illustrated in Fig. 3, where 
we see its usage in defining the CommonKADS domain-schema constructs. 



3.2 Task and Inference Knowledge 

As outlined above, the task- and inference-knowledge constructs were modeled as 
Protege classes. An example class definition is shown in Fig. 1 for a task method. The 
slots correspond to the information that needs to be specified for a task method in the 
CommonKADS knowledge-modeling language [1 1, Appendix]. 

To represent the CommonKADS task-method decomposition and inference dia- 
grams, we configured two specialized diagrammatic classes in our ontology, as well 
as their associated forms, along the lines described in Sec. 2.1.® For example, we de- 
fined the InferenceStructureDiagram class with nodes (inferenceStructureNodes) to be 
instances of the TransferFunction, KnowledgeRole and Inference classes (and subclas- 
ses) and connectors to be instances of special-purpose connector classes. For example, 
the HasInputRole connector links a DynamicRole (subclass of KnowledgeRole) node 
to a Inference or TransferFunction node. This way, when we create an instance of the 
InferenceStructureDiagram (see Fig. 2), we can add or create instances of the nodes, 
for example an inference abstract and a dynamic role case description, and link them 
with an instance of HasInputRole connector. Based on the definition of HasInputRole, 
the diagram automatically fills-in the slot inputRoles of the Abstract instance with the 
instance value case description. 

The use of the diagrams gave rise to a large set of small problems and requirements 
with respect to their usage (symbol availability, user-interface behavior, etc.). We can see 
some small graphical differences (e.g., rounded rectangles, no border) when we compare 
the inference structure in Fig. 2 with the original figure in the CommonKADS textbook 
[1 1, p. 136]. However, the basic mechanisms for form specification suited our purposes 
well. 

® For details, see the Protege tutorial on the use of the “diagram widget” at 
http: //smi-web. stanford.edu/projects/protege/protege-2000/doc/tutorial/ 
diagrams/ index . html 
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Fig. 1. Specification of the classTaskMethod. At the left, part of the hierarchy of classes is shown. 
TaskMethod is a root class (i.e., a subclass of :THING, see lower-left). At the right, the class 
definition is shown. The own slot role indicates whether the class is concrete (can have direct 
instances) or abstract (no direct instances). Abstract classes are marked with an “A” in the class 
hierarchy. In the lower-right area the template slots of TaskMethod instances are defined. Each 
slot has a value range, a cardinality constraint (single or multiple), and a possible value restriction 
(e.g. the slot realizes can only be filled by instances of the class Task, as shown in the pop-up slot 
definition window). 



3.3 Domain Schema 

In principle, one can specify several different domain schemata in a knowledge model. 
For the moment we have limited the tool to a single schema. A schema contains a set of 
definitions of concepts, relations and rule types. A concept is represented as a class. The 
attributes of the concept (which in CommonKADS, as in UML, always point to atomic 
values, and not to other concepts) are modelled as slots. 

To ensure that the attributes of a concept are atomic, we defined a constraint on the 
DomainTypeMetaClass metaclass, which is the template for all domain-modeling con- 
structs such as the class Concept (see below). The constraint specifies that all subclasses 
of Concept (which define domain-specific types, such as Applicant) should have their 
template slots restricted to primitive (atomic) value types, such as string, boolean or 
integer. The following formula is the constraint expressed using the language provided 
in Protege: 
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Fig. 2. Instance of an inference structure diagram for assessment. We defined the specific Infe- 
renceStructureDiagram as a subclass of the NetworkClass, thus also an instance of the Net- 
workMetaclass, that has additional slots to hold nodes and connectors. Our specific connectors 
are subclasses of ConnectorClass and instances of the ConnectorMetaclass. At the right, the 
form for acquiring an inference structure shows the instance created for an assessment task. It 
includes a palette of graphical elements from which the diagram can be constructed. 



(def range ?dtype : FRAME DomainTypeMetaClass) 

(def range ?att : FRAME : STANDARD-SLOT) 

(forall ?dtype (forall ?att 

(=> (and (subclass-of ?dtype Concept) 

(template-slot-of ?att ?dtype)) 

(allowed-slot-value-type ?dtype ?att : PRIMITIVE-TYPE) )) ) 

Fig. 3 shows an example concept Applicant, i.e a person applying for a house. The 
slots describe attributes of the applicant that can be used for assessment purposes. In Fig. 3 
we can also see the class-instance issue discussed in Sec. 3.1. The class Applicant is at the 
same time a subclass of Concept and an instance of the metaclass DomainTypeMetaClass. 
This metaclass has a slot rolesPlayed. The fillers of this slot are the knowledge roles that 
refer to this domain type (here: case description and abstracted case). 

A relation in CommonKADS is a “first-class citizen”, meaning that it can have 
attributes. As explained in Sec. 2.1, slots in Protege-2000 are also first-class objects, 
that are instances of a metaslot class. However, slot frames cannot form a slot hierar- 
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Fig. 3. Specification of tbe concept Applicant. The figure illustrates the three-level specification of 
the CommonKADS knowledge model. The domain-specific class Applicant is both a subclass of 
the domain-modeling construct Concept, and an instance of the special-purpose DomainType- 
MetaClass metaclass (shown in the :CLASS subtree). Therefore it has an additional own slot 
rolesPlayed that can be tilled-in in the right hand form. Also, it only defines slots of primitive 
value type. Individual applicants are instances of Applicant class, that have specific values for the 
template slots age, name, etc. 



chy. Therefore, we do not model relations as slots but as domain classes (instances of 
DomainTypeMetaClass). Each “relation” class should have at least two slots that point 
to the object types being related (the relation “arguments”). These object types can be 
concepts and relations, meaning that higher-order relations are allowed (cf. the notion 
of “association class” in UML). The name of the slot pointing to the argument defines 
the role the argument plays in the relation. Other slots may be added to define attributes 
of the relation. 

The representation of a rule type is more complex. Rule types model relations 
between expressions about concept/relation slots. Therefore, we first have to define the 
notion of “expression”. We decided to model an expression as a class with four slots: 

1 . The concept/relation involved in the expression. 

2. The possible slots involved. This should be existing slots of the concepts/relations 
involved. 

3. An operator such as equal, not-equal, greater. The set of legal operators depends 
on the slot involved in the expression. 




A Case Study in Using Protege-2000 



43 



4. The value: this should be a legal value for the slot involved. 

With this expression construct we can define a class ApplicantExpression. An example 
instance of this expression could have the following slot values: 

class = Applicant, slot = age, operand = greater, value = 22 

The intended interpretation of the expression instance is that “the age of the applicant 
should be higher than 22”. 
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Fig. 4. Definition of the class Expression as an instance of DomainTypeMetaClass. The four 
slots that are attached to it have additional constraints on their value (bottom right). First, the slot 
slot involved in the expression should be an existing slot of the class involved. The KJF-based 
formula for this constraint is displayed in the pop-up window: it defines the range for the variables 
and the actual sentence of the constraint. A second constraint specifies that the value involved in 
the expression should be a valid value for the slot attached to the class involved. 



Fig. 4 shows the definition of the Expression class. Besides the usual value-type 
restrictions on slots we specified constraints to express the above definition of an ex- 
pression. We defined a first constraint to restrict the value of the slot involved in an 
expression (the value of the slot slot) to existing template slots of the class involved (the 
class value of the class slot). We defined a second constraint to ensure that the value 
involved in an expression (the value slot) is legal for the slot involved (the slot value of 
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the slot slot at the class value of the class class). Constraints can subsequently be used 
to check the validity of expression instances (example omitted for reasons of space). 
A special-purpose constraint checking tab can be plugged in to Protege user interface 
and enable the user to trigger the constraint-checking engine on the knowledge base and 
view violations. 

We can now model a rule type as a relation between a set of expressions which 
form the antecedent of the rule and a set of expressions which constitute the consequent. 
For example, we defined the rule type ApplicantAbstraction as a subclass of RuleType, 
and specialized its inherited slots antecedent and consequent so that their value type is 
restricted to instances of ApplicantExpression. In the next subsection we see examples 
of the actual rule instances, and how we can define specialized forms for entering rules 
of a particular type. 

3.4 Knowledge Bases 

In CommonKADS there is not one large knowledge base. Instead, several knowledge 
bases are defined. Each knowledge base contains instances of a designated set of domain 
types. Most commonly, knowledge bases contain instances of rule types, i.e. the actual 
“rules”. Knowledge bases are modelled as classes with a slot pointing to the rule types 
or other instances to be included in the knowledge base. Fig. 5 shows an instance of a 
knowledge base Abstraction RuleSet. This particular knowledge base contains two rules, 
both concerning a simple abstraction in the sample application. Using Protege’s set of 
built-in user interface elements in a customized way, we defined a specialized form for 
acquiring instances of KnowledgeBase classes, shown in Fig. 5. This enables the user 
to browse and create knowledge bases in a synthetic way, acquiring their rules and the 
expressions that form the rules immediately from the same form. 

4 Discussion 

This case study does not provide us with a formal evaluation. Still, a number of remarks 
can be made. It should be noted that the remarks are made from the perspective of using 
Protege as a “metaCASE” tool. This typically requires stretching the possibilities of 
a tool to its limits. A standard case study using Protege only directly as an ontology- 
editing tool would have given rise to different remarks. In the discussion below on the 
strong and weak points of Protege we refer back to the three user types mentioned in the 
introduction: tool builder, knowledge engineer, and domain specialist. 



Strong points. The main strong point of Protege is that it supports at the same time 
tool builders, knowledge engineers and domain specialists. This is the main difference 
with existing tools, which are typically targeted at the knowledge engineer and lack 
flexibility for metamodeling. This latter feature makes it easier to adapt Protege to new 
requirements and/or changes in the model structure. 

For the tool builder Protege combines an expressive framework with a consistent way 
of generating editor interfaces (the forms). As mentioned, the metaclass mechanism in 
which classes can be modelled as “real” instances of metaclasses is an indispensable 
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Fig. 5. Example knowledge base with two abstraction rules. The form for acquiring instances of 
KnowledgeBase has been highly customized to present a synthetic view of the rules contained 
in a knowledge base by way of container and table graphical elements. First, we customized the 
form for acquiring RuleType instances to display its antecedent and consequent slots as rows 
that enable in-place editing of slot values. Then, we “included” this RuleType fonn in the form 
for KnowledgeBase instances. 



feature. Also, the fact that classes (as opposed to instances) can serve as the range of 
a slot is a useful feature (although this is also common in other languages). Another 
positive point is the time required to build a tool. Constructing a first version is a matter 
of a few hours. In this case study a number of revisions were made, but this is more or 
less intrinsic to the complexity of metamodeling in general. 

Although still preliminary in terms of scope and user interface, an important feature 
for the tool builder is the possibility to define constraints on the classes and slots being 
defined. This provides a means for the knowledge engineer to check model completeness 
and correctness. In the context of this case study we specified a subset of the constraints 
for CommonKADS knowledge models, but it should be straightforward to generate a 
full set. In particular, we will express the third constraint on expressions (see Sec. 3.3), 
to ensure that the set of legal operators offered on a certain type of expression (subclass 
of Expression) is suitable for the type of slot involved in the expression. 

It is to note that during construction the models are by definition incomplete or 
even inconsistent. Therefore, a verification mechanism should preferably be explicitly 
invoked by a knowledge engineer, and not be done automatically by the tool. The fact 
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that the tool offers this approach of decoupling the acquisition phase from the constraint 
checking phase is a strong point. It goes further in enabling the check constraints step 
by step, for example locally to a class. The constraints we created in our modeling study 
range over class seen as instances of metaclasses (e.g., Expression, Concept) and restrict 
or bind the value-type of slots (rather than the value itself). That is again an important 
aspect of metamodeling. 

A nice feature for the knowledge engineer is that it proved possible to generate 
diagrammatic editors close to the representation used in CommonKADS. The additional 
requirements here are really on a very detailed, uninteresting level, having to do with 
the availability of particular graphical symbols, labels, etc. Also, the RDF support is 
potentially a positive feature of Protege, because it makes import into and export from 
the tool feasible in a standard format. This is traditionally problematic for CASE tools 
supporting only a proprietary format. 

Finally, it should also be noted, that the fact that the tool never crashed during this case 
study also greatly helped in creating user confidence (especially with the first author). 



Weak points and opportunities for improvement. Currently, Protege only has a simple 
inclusion mechanism for importing definitions. In order to make use of libraries of exi- 
sting partial models that the user can specialize and adapt, a more refined import/export 
mechanism for sets of class/form/instance definitions is required. 

Another drawback is the fact that a single interface is used for all types of users. 
In particular for the domain specialist, it should be possible to create a stand-alone 
interface with just the forms for entering domain knowledge. This ensures that the 
domain specialist does not get confused by modeling details. The same could hold, to a 
lesser extent, for the knowledge engineer. 

At the time of this case study. Protege was not able to handle the automatic filling 
of inverse slot relationships, for example the domainMapping and rolesPlayed slots of 
respectively knowledge roles and domain types. This would be a useful extension, as it 
prevents redundancy and omissions in the interface for the knowledge engineer (in fact, 
it is now being implemented). 

The expressiveness of the predefined forms could be extended in a number of ways. 
For example, the diagram widget could be extended to enable the creation of UML-type 
diagrams [2]. For CommonKADS this would open the possibility to create domain- 
schema diagrams, which use the UML conventions. It could also be a powerful way 
to set and visualize constraint links among classes. Another advantage would be that it 
makes Protege potentially usable as a CASE tool for object-oriented analysis. 

Rule types proved to be difficult to represent. The negative effect is mainly felt 
in the knowledge-elicitation interface created for the domain specialist. The somewhat 
contrived way of representing rule types diminishes the naturalness of the interface for 
entering rule instances in a knowledge base, as we saw in Sec. 3 .4. It would be worthwhile 
to study more in detail the user-interface requirements for editing this type of expertise 
data, and adapt the tool accordingly. We could define a custom user interface component 
that would be more intuitive and synthetic to acquire rule bases, and would also check 
constraints on expressions locally. 
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Protege and CommonKADS. Beyond the engineering details of the tool, we can draw 
conclusions from this case study about Protege, CommonKADS, and their relationship. 
CommonKADS-type modeling is a highly abstract activity. Protege helps to represent it 
in an understandable way, to focus users’ attention on certain parts of it, and to constrain 
it. The self-contained expression of the (meta-)model makes it easier to understand 
it and to instantiate it. More is needed in terms of knowledge-elicitation metaphors 
to guide users in building a knowledge model following certain steps. As mentioned 
before, UML diagrammatic notation and full support in translating it to CommonKADS 
models would also narrow the cognitive gap between Protege and CommonKADS. Also, 
inclusion and reuse of model templates from catalogs would significantly augment the 
tool’s usefulness. 

Protege and CommonKADS target different levels/ways of modeling. Common- 
KADS has a clearly identified methodology divided in different models and modeling 
steps, powerful but complex to embrace and instantiate. Protege’s methodology is very 
straightforward (a cycle of metaclass/class definition, form customization, and instance 
acquisition). It is completely independent of any given application or domain, and ma- 
kes no assumption on what it is used for (besides the frame-based conceptualization of 
a domain). Therefore it enables concrete and immediately usable systems to be built. 
Protege-based knowledge models are storable in different electronic formats, therefore 
can be queried and used in different applications. So the main benefit that Protege brings 
to CommonKADS lies in the way the metamodel can itself be modeled in Protege and 
in the way the acquisition of models and application instances can be customized and 
constrained. The tool that we have built in this case study provides a uniform framework 
that embraces the three-level approach of modeling a KBS using one representation 
formalism. 

We limited this case study to the central knowledge model of CommonKADS with 
only one domain schema. Building a full CASE tool for CommonKADS would require 
extending the Protege-CK tool with the other CommonKADS models, following the 
same principles. We would also need to specify the interaction links among those models 
in the form of inter-model constraints. 

Finally, this case study shows how important metamodeling constructs are in spe- 
cifying ontologies. Simple class/instance distinctions are insufficient for describing real- 
life conceptualizations. It is high time this requirement is taken seriously in ontology- 
specification research. 



Some final remarks. We plan to use the resulting CASE tool in an experiment in which 
a group of students in knowledge engineering at the University of Amsterdam uses the 
tool to construct knowledge models. The experiment is planned for the end of 2000. We 
will divide the students into two groups, one working with a baseline drawing tool, the 
other group with the knowledge-engineering interface of the Protege-CommonBCADS 
tool. This experiment will hopefully provide us with more precise data on usability. 
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Abstract. Development and maintenance of knowledge intensive software ap- 
plications is a complex and expensive activity. By employing a systematic ap- 
proach long term risk can be reduced. The ESPRIT-IV funded project called 
MOKA, (No. 25418), defined a methodology for Knowledge Based Engineering 
(KBE) application development. Results include a modelling language, called 
the MOKA Modelling Language (MML), dedicated to KBE application devel- 
opment that models engineering product and process knowledge at one level of 
abstraction above application code. MML is based on the Unified Modelling 
Language (UML). This paper describes the philosophy of MML, how it is re- 
lated to UML and provides examples of its use. 



1. Introduction 

Engineering knowledge is complex, diverse, and interrelated, involving implicit 
knowledge, tacit knowledge, background knowledge and underlying assumptions. Flow 
to manage knowledge effectively is a key issue in many companies today. They wish 
to capture and reuse, to reduce the time to find solutions, to build products “right first 
time” and to retain best practice. 

Knowledge Based Engineering (KBE) automates engineering design tasks by embed- 
ding engineering knowledge within software applications. Leading industrial compa- 
nies exploiting KBE have shown dramatic return on investment. BAE SYSTEMS for 
example has achieved dramatic results automating wing box design tasks on the Airbus 
A340-600 aircraft. 

Development and maintenance of complex KBE applications requires both Knowledge 
Engineering and Software Engineering techniques. Knowledge must be captured, 
represented, validated and maintained. Software must be specified, designed, coded 
and tested. The scarce skills needed to perform all these tasks, encourages the use of a 
systematic approach within large development teams to facilitate long-term mainte- 
nance and re-use. 

R. Dieng and O. Corby (Eds.): EKAW 2000, LNAI 1937, pp. 49-56, 2000. 
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The ESPRIT funded project called MOKA, (EP 25418), has defined a methodology to 
capture and formalise engineering knowledge, allowing it to be retained and exploited, 
for example within KBE applications. This paper discusses part of that methodology, 
namely the MOKA Modelling Language (MML), a Unified Modelling Language 
(UML) extension used to formally model engineering knowledge at one level above 
KBE application code. 



2. Requirements for a KBE formal modelling language 

MOKA identified two engineering knowledge models as key artefacts in the KBE 
application development lifecycle [1]. 

Informal Model Structured, natural language representation using pre- 
defined forms [4] 

Formal Model Graphical, object-oriented at one level of abstraction 
above application code [2]. 

The language must be capable of formalising all useful knowledge. It must provide a 
mediating language between experts, knowledge engineers and software developers, 
simple yet expressive and preferably graphical. Formal enough to support code gen- 
eration. User extensible and customisable to capture best practice within an organisa- 
tion and allow models to be organised according to local style. 



3. The MOKA Modelling Language 

UML exhibits most of the characteristics required by MOKA; it is graphical, object- 
oriented, extensible, etc. It is however general-purpose and a more dedicated language 
was created that more readily supports the KBE domain. This is the MOKA Modelling 
Language [2]. 

MML plays an advisory role within KBE development. It is not rigid in its definition, 
nor is it to be rigidly applied. MML captures best practice by pre-defining classes, 
associations and attributes and offering these elements to MML users in a structured 
and logical way. The aim is to provide a framework and guidance to the modeller, to 
enable organisations to build and capture modelling experience, not to dictate what can 
and cannot be modelled. It is an extension of UML and users are free to model at the 
UML level as required. Alternatively, users may extend the core MML definition to 
tailor it to their particular concern. MML is achieved by providing and organising the 
following : 

■ Pre-defined views - provide different perspectives on the underlying model and 
consequently an expected content for diagrams. The core MML definition is pre- 
sented through Functional, Structural and a Behaviour views. 
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■ Pre-defined classes - represent meta-classes identifying the type of classes ex- 
pected to be created by users. For example, a <Part> is a pre-defined class and us- 
ers are expected to create classes of type <Part>. 

■ Pre-defined class attributes - capture commonly used attributes for a particular 
type of class. For example, the meta-class Assembly has a pre-defined attribute 
called Assembly jOperation. 



4 . MML Product Modelling 

The MOKA Product Model represents a family of products by building product model 
diagrams, defining product model classes and maintaining a product model constraint 
table. Product model classes identify and describe generic product family components 
- e.g. chassis, body, brakes - where instantiating a class produces an object in the final 
product model instance. 



4.1 Product Model Views 

The core MML definition has the following views; Structure, Function, Behaviour, 
Technology and Representation. Users are encouraged to consider these as a basis for 
building their own product model. As an illustration, the functional view is described 
here (see Fig. 1). 



+satisfied by 



Function 



Behaviour 

(from Behaviour View) 



Structure 

(from Structure View) 



+embodied by 




Fig. 1 : The Functional view 



A Function is something that the product must do in order to be successful. A product 
may be required to generate heat, or to amplify a signal. Top-level functions are de- 
rived from higher level objectives - e.g. the product must keep its occupants warm - 
and subsequently decomposed into sub-functions until they are directly solvable by 
either a technical solution or a principle of solution. 
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4.2 Product Model Constraints 



Constraints represent generic design restrictions that must be satisfied. For example, 
the dimensions of a component are often constrained by the dimensions of another. 
MML classifies product model constraints according to the way they are modelled 
within MML product model diagrams: 



Attribute-Bound 
Class-Bound 
Association-Bound 
Existence constraints 



Constraints scoped within the boundaries of an 
attribute; e.g. X < 10 

Constraints scoped within the boundaries of the 
class; e.g. ClassA.X < ClassA.Y 
Constraints scoped by association links be- 
tween classes ; e.g. ClassA.X < ClassB.Y 
Constraints related to the existence of objects 
within the final product model instance. 



5, MML Process Modelling 

The MOKA design process describes how a Product Model Instance is derived from a 
Product Model. It describes how to resolve product choices, subject to product con- 
straints, and the order in which steps are executed and decisions made. 

An MML design process model can be presented to users in different ways. The pre- 
ferred approach is to use extended UML Activity Diagrams, though current software 
support can limit users to using UML class diagrams. 



5.1 Static and Dynamic Processes 

Design activity sequencing is not always fixed and different strategies, giving different 
execution orders, can be adopted depending on runtime conditions. Consequently, 
MOKA makes a distinction between static and dynamic design processes : 

■ A static design process is one where the activity order is pre-defined. 

■ A dynamic design process is one where the order of execution is de- 
termined at runtime. 

The MOKA design process model captures activity decomposition, serial and parallel 
execution flow, branching, synchronisation, static and dynamic processes. To accom- 
modate this, the UML Activity Model is extended to include two new classes; Com- 
pound Activity and Elementary Activity. 
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6. MOKA Formal Model Examples 

This section shows a modelling example developed during the MOKA project ex- 
tracted from the Aerospatiale test case on Fuselage design (see Fig. 3). The main 
function of the panel is a structural element of the aircraft section. There are different 
principles of solution, one of these is to stiffen the panel. There are two sub-principles 
of solution to this, either stiffeners (stringers) are fastened to the panel, or the panels 
are designed in such a way that they integrate the stiffeners. A technical solution to 
fasten the stiffeners is to use riveting. The technical solution “riveting” requires fasten- 
ers and holes in the panel and in the stringers. Those are Features type classes defined 
within the Structure view. 




Fig. 2 : Function view example 
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/ «Compound activity: 
{ Initialise 






) 



/«Compound activity»\ 
f Optimise j 

V superstringers J 



A<Compound activi'ty>^ 
[ Design stiffened panel ] 






I 



«Elemenlary actwlty» \ 
Load the master-geometry J 
of the workpackaqe / 

T ; 

<<blementary activity»' 
Define the panel 
boundaries 

T 

x<Elementary activity>y 
Load thehbM tile 



1 



Seqwenf/a/ a/xf svbprocess 
"Initialise" 



Inputs ; workpackage. reference 
Outputs . wurkpaukage-inasler-yeurnelty 



Inpirt<5 wnrkparksgft-mastfir-gfinmptry 
Outputs istringers reference, frames 
references 






Inputs : workpackage. reference 
Outputs ;fem-rods, fern-quads, fern-nodes 






,nical solution=riveting ] 



Elementary activitjf» 
Select the panel 
material 



<<Elementary actlvity» 
Select the preference list among 
standard stringer sections 



[ de^ner not satisfied ] 



<<Bementary activity» 
Define new stringer 
sections 



[ designer satisfi 



<<Compoufld activit/>> 
Calculate the optimisation 



«Bementary activity» 
Select the fasteners 



entry/ if (Siiffened-panel. Stringers Number < 5) then do (fraction, compression) else (compression, traction) 



and static suPprucess, with pafahei tashs 
"Optimise suoarsthnoers" 



Fig. 3 : Design Process Model Example 



7. Discussion 

To build a formal model, developers require a modelling language. As described in 
[4], there are various methodological approaches available : 

■ CommonKADS [6] or the comparable approach KARL [7] as a methodology 
of knowledge-based systems. 



The MOKA Modelling Language 55 



■ KIF/Ontolingua , formal ontology based knowledge representation [8], [10]. 

■ General object oriented modelling techniques like UML [3]. 

Each of these provides valuable input to a methodology of knowledge-based engi- 
neering, but none is powerful enough to immediately fulfil all the needs. 

CommonKADS is based on a general classification of knowledge and is more or less a 
de facto knowledge-based methodology standard today. The knowledge representation 
and problem-solving requirements in KJBE applications tend to be not so demanding. 
More complicated problem-solving methods as needed in many engineering applica- 
tions and the flexibility which is necessary in order to support user interactions are 
major open research issues in this field. 

KIF/Ontolingua is a very expressive knowledge representation approach, with good 
examples of ontologies including engineering relevant domains. However, experiences 
show that the approach is currently underdeveloped for industrial application. Research 
question include determining the right granularity of model representation and com- 
prehensible representation of the many relevant and interrelated aspects. 

Object oriented methods like UML have shown increasing popularity because of their 
expressiveness, flexibility, and ease of use. However, these are general-purpose and 
within a particular domain this is a weakness; object orientation alone does not provide 
the necessary clear semantics. The main advantage of modelling engineering knowl- 
edge in UML - as shown in our test cases studies [9] - is the expressiveness of the 
language, the possibility to customise and the graphical support available during mod- 
elling. 

MOKA has chosen to extend UML, using standard UML mechanisms, to target it 
towards the engineering domain. The resulting extension is called the MOKA Model- 
ling Language (MML), a graphical object-oriented modelling language, used to repre- 
sent engineering design knowledge at a user level for deployment in KBE applications. 
There are still unanswered questions, including the granularity of MML and its appli- 
cability to non-KBE knowledge engineering activities. 
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Abstract. Mdoj<; is a semi-formal modelling language allowing to model 
graphically static knowledge of a domain under the form of a conceptual 
network. It makes easier the model translation into a representation for- 
malism as description logics and conceptual graphs. Mdui<; is part of a 
more general method designed to build domain ontologies from French 
texts. The approach has been proposed in the context of an industrial 
application concerning the supervision of telecom networks. Using Mduj<; 
implies modelling before formal representation in order to avoid the pit- 
falls of direct representation. Choice of a formalism and its implementa- 
tion is allowed to be postponed until the representation needs are better 
known. 



1 Introduction 

This paper presents the results of an industrial experiment concerning the super- 
vision of complex telecom networks^. The initial purpose of our study concerned 
the comparison of knowledge representation formalisms such as description logics 
or conceptual graphs (DL and CG in what follows). Although these formalisms 
are not totally equivalent [5], our objective was to compare their usability. These 
formalisms allow the representation of static and generic knowledge which cor- 
respond to a domain model. Problem solving knowledge can only be represented 
outside these formalisms and have not been considered. 

The representation of real-world knowledge shows that the trouble of repre- 
sentation into a formalism is due not only to the expressiveness of the formalism 
and from the skill of the knowledge engineer, but also mainly from the difficulty 
of conceptualisation. Direct representation is a difficult and dangerous endea- 
vour, which leads to poor systems. Both DL and CG are among the most widely 
used formalisms in knowledge representation, but formal problems are only ta- 
ken into account and the modelling problem is never tackled per se. The well 

^ Granted by CNET/CNRS cognisciences. Centre National d’Etudes des 
T elecommunications 
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known problem in knowledge engineering is not how represent knowledge, but 
how model it. Nevertheless, some recent studies on ontology building stress that 
direct representation is still common and comes up against known problems in 
knowledge engineering [2]. Thus formalisms are not directly usable, it is neces- 
sary to build up a model and then to translate it into the formalisms. To compare 
CG and DL usability does not come down to confront the representation in one 
language to the other; protocol is based on a common model and compare the 
consequences of the translation of each piece of the model into each formalism. 

We have therefore defined Md^^, a modelling language translate the resulting 
model into either one formalism or the other, by using some rules governing the 
translation. Its use postpones the choice of a formalism and its implementation 
until the representation needs are better known. With this language, modelling 
uses semantic network. Md^n; generalises the expressive power of both of the 
formalisms. It is semi-formal language: syntax is rigorously defined as well as 
some semantic rules to avoid some bad uses of the language. is coupled 

together with a graphical tool that controls the syntax and the semantic rules. 

In our telecom application, the domain knowledge have to be discovered 
from texts. Therefore, a corpus has been build and linguistically analysed using 
principles proposed by the French TIA^ group. Terms with their description in 
natural language have been extracted. Our work comes within the scope of the 
current trends in knowledge acquisition from texts which involves terminology 
and natural language processing (NLP). These recent works allow the acquisition 
of terminological knowledge by applying NLP-tools to a corpus. The first results 
lead to the definition of a ’’terminological knowledge base” [1]. Among the most 
recent works, [4] propose a method for building formal ontologies from a linguistic 
analysis of texts. 

We design a method to help a knowledge engineer to model and represent 
knowledge from texts. This method guides the extraction of the conceptual pri- 
mitives of the domain from the set of terms resulting from the linguistic analysis, 
as well as their modelling under schemata. All these models form a domain 

ontology that can be formalised in CG as well as in DL using some translation 
rules. The tool supporting Mda,,; offers a graphical modelling by successive re- 
finement from the text study to the formalisation, keeping the link to the text. 
The language offers a user-friendly touch with its graphical syntax and the links 
to the texts then it avoids the pitfalls of direct representation. Language and 
method are implemented in Java. 

A longer version of this paper with a comprehensive state of the art may 
be found at [8]. Section 2 presents the language. Section 3 describes the 

method, the language and the tool on an example taken from the telecom appli- 
cation. Some general translation rules are explicited there. 

2 Md^^: A Modelling Language for CG and DL 

We describe now the language objects. Building an ontology in Md,^^ starts with 
the constitution of a corpus, a set of documents which describe the domain and 

^ the Terminologie et Intelligence Artiiicielle group is a working group of the APIA, 
French Association for Artificial Intelligence. 
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the application. Then, the conceptual primitives (CPs in what follows), basic 
items of modelling, have to be extracted from this corpus. A CP is for us an 
expression which corresponds either to a term or to a relation between terms or 
between relations. 

2.1 The Objects of the Language 

The language includes three types of objects, concepts and properties, which 
correspond to CPs, and schemata. Some comments, which may be text or attri- 
butes, are attached to concepts and properties. 

Concept A concept is described by its name and by the set of properties that 
relate it to other concepts, in some schema. Each concept is associated with a 
level, a state and a nature. The level is the depth of the concept into the ontology. 
The state indicates the progress of the modelling of the primitive. The nature 
specifies the origin and the role that the primitive plays in the modelling. This 
information makes the modelling and the maintenance easier. 

1. Concept level: The level is useful when modifying a concept : the closest the concept 
is to the top of the ontology, the most important would be the consequences on 
the whole ontology. 

2. Concept state: Modelling is a long phase, it is usual to give a partial model of a 
primitive. States may have one of four values TopConcept, Stated, Statel, State2. 
The TopConeept is the highest one in the specialisation hierarchy, only described by 
its name. A concept is State2, if its description is completed, i.e. all its properties 
have been described with schemata. So, it cannot be modified any more. In all 
other cases, a concept is under modelling. Stated with only hierarchy properties in 
its description, Statel with other kind of properties. 

3. Concept nature: There is two kinds of nature, a structural and a linguistic one. 
The structural nature explains the role of the concept in the modelling, it may 
have the values grouping, structural, auxiliary. A concept r has value grouping, if 
its properties are included in the properties of a set of concepts already described, 
which are thus more specialised than r. A concept has value auxiliary, if it is only 
introduced to describe more easily a CP. In all other cases, the concept has value 
structural. The structure of a concept plays a part in case of modification. So when 
modifying a grouping concept, it is important to take care of the coherence of the 
factorisation of properties. 

The linguistic nature specifies the link of the primitive with the corpus, it may 
have the values terminological, pre-terminological, not terminological. A termino- 
logical nature expresses that the primitive comes from the corpus, its description 
corresponds to the definition of a term. A pre-terminological nature expresses that 
there is no agreement, among the experts of the domain, on an expression that 
may describe the primitive. In all other cases, the nature is said not terminological. 
When a concept is created, its nature by default is the couple (structural, not ter- 
minological) . 

Property A property is described by its name, its type, its nature, by the set S 
of CPs that are source of the corresponding link and by the set C of CPs that are 
target of this link. The arity of a property is the sum of the cardinality of S and 
C. A property may have a cardinality; the most used property is specialisation, 
of concept or property. 
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1. Property type: It is a couple of binary values, which is deduced from the property 
description: simple vs calculated, and basic vs specialised. 

A property is said simple if its description includes only concepts as its source or 
as its target; it is said calculated if its description needs another property as its 
source or as its target. 

A property is said hasie if it is not more specific than any other property, it is 
specialised in the opposite case. 

2. Property nature: The nature of a property is only linguistic, it takes the same 
values as a concept. 

3. Property cardinality : In case of binary link, a [min, max] couple can be associated 
with the property. Min and max are two integers that represent the minimum and 
the maximum numbers of objects that can be the target of the property for any 
given source concept. The default cardinality is [0,n]. 

4. Specialisation: The specialisation of a concept is a binary basic and simple pro- 
perty used to structure the ontology. Its name is omitted on the schemata. 

The specialisation of a property may concern its target or source CPs as its cardi- 
nality. The specialisation of a property is an example of calculated property where 
the target is a more generic property, and the source a more specialised one. 

5. Calculated property: A calculated property expresses some complex process bet- 
ween heterogeneous CPs, it is annotated to describe the calculation that it models. 

Annotation of conceptual primitive An annotation is a comment attached 
to a primitive; it may consist of text, or of an attribute with its value. Some com- 
ments are compulsory, as the attributes giving the name, state, type and nature 
of the primitive. These comments are represented graphically on the schemata 
by labels, colors or specific forms. The text does not appear on the schemata 
but on an hyper-text document to keep the schema legibility; it includes: 

1. the reference term if the primitive nature is terminological; 

2. some information on the choices made for modelling the primitive; 

3. the links to the corpus, when the nature is terminological or pre-terminological; 

4. the cardinality of a property; 

5. the explanation to compute a calculated property. 

Schema A schema is a semantic network which models one or several primitives. 
The name, state, type and nature of a primitive are the same in all schemata. A 
schema is a part of the ontology which is formed of the set of all the schemata. 

2.2 Control in 

Mdai<; is also a modelling tool which controls the correctness of the schemata 
relatively to the previous definitions and the respect of some semantic rules. 
When a user’s action does not obey some rule, the action is not realised and the 
user is warned. These rules characterise the semi-formal feature of Md^ip. 

1. Unicity of the name of a CP: The name of a primitive is the same in every schema, 
but the same name may be given to a property and to its specialisations. 

2. Compatibility of cardinality of property: In case of specialisation of property, the 
cardinality of a simple binary property must be less or equal to the one it specia- 
lises. 
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3. Constraints on specialisations: A concept inherits the description of each concept it 
specialises. Its properties may either be basic, or specialise a more generic property 
of a concept that it specialises. 

4. Constraints on the state and nature of a concept: The state and nature of a concept 
are the same in all the schemata. A concept in State2 cannot be modified anymore, 
it cannot be source of a new property. There exists one and only one TopConcept. 

3 Method 

We present the language and tool on some examples coming from an industrial 
experiment concerning the supervision of telecom networks (see [6]). 

3.1 The Supervision Domain 

Supervision consists in making a real-time diagnosis of the incidents that happen 
in a complex telecom network, the diagnosis being based on the observation of the 
state of the network. A network is composed of equipments connected together, 
mainly beams and switches. When some incident happens on the network, se- 
veral indicators are positioned (lights, messages, curves...). These indicators give 
information on switches, beams, and traffic. Then, an operator provides a dia- 
gnosis concerning the type of the incident. With this diagnosis, he/she should 
perform some action to inhibit the consequences of this incident on the network. 
Our job concerned building an ontology to allow a description of every incident 
from the alarms, which appear in the supervision room. Having no access to 
the site, we had to build the ontology from the various documents put at our 
disposal. Nevertheless, an expert could validate our results. 

3.2 Modelling Phase 

First, a corpus has to be defined relatively to the objective. A candidate-term 
extractor [3] allows the automatic extraction and further expert validation of the 
main terms of the domain. This gives a list of CPs. During the modelling, the 
name given to the primitive should remind of the associate term. From this first 
and often very long list, the knowledge engineer looks for primitives that describe 
the main sub-domains of the ontology. These primitives structure the ontology, 
they are modelled as concepts and they form the initial list of modelling CPs 
(LMCP). In the application, it is the case of ’’alarm”, ’’incident” (figure 1). 

Each primitive of LMCP is described in natural language. This description 
is considered as a new document, from which a new list of conceptual primitives 
is created. The knowledge engineer looks in this list for: 

1. CPs that express a relation between high-level concepts, 

2. primitives already present in the initial list, 

3. new primitives only present in this list. 

In our application, the first case leads to define basic properties between high- 
level concepts, like ’’toBeDisclosedBy” or ’’toBeAbout” (figure 1). Cases 2 and 
3 give new high-level concepts like ’’cause” (figure 2) and so allow to build up 
the LMCP. 
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The method is therefore based on a process of successive refinements of the 
CPs initially selected. 

At each iteration, new schemata are created and the previous are updated; 
especially, the state and nature of a concept may change. An expert must as 
soon as possible validate the schema of the high-level ontology to stabilize the 
different sub-ontologies. Once a stable state is reached, the other primitives of 
the initial list are gradually modelled and added to the LMCP. 

Let us suppose that the CPs on equipment, incidents and actions, are already 
modelled, and let us apply this process to the term ’’duplex stop incident”. Pre- 
sent in numerous technical documents, this primitive, that will be called ”du- 
plexStop” , is described as follows: ”A duplex stop incident is disclosed by one simplex 
stop alarm, one or more overloading alarms and at least three null efficiency alarms. 
The alarms of type simplex stop are alarm events on switches. The alarms of type over- 
loading and the alarms of type null efficiency provide information on the state of the 
beams”. This description includes many CPs, among which ’’duplexStop” (inci- 
dent of type duplex stop), ’’simplexStop” (simplex stop alarm), ’’overloading” 
(alarm of type overloading of beams), ’’nullEfficiency” (alarm of type null effi- 
ciency) are not yet modelled. The table 1 presents the LMCP before inserting 
these new primitives; it tells for each primitive if it is modelled by a concept or 
by a property, and gives the level of concepts or the type of properties (Basic or 
Specialised) . 
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Fig. 3. Use of calculated property 



Fig. 4. Example of grouping concept 







Table 1. Example of conceptual primitives 



Conceptual primitives (Concept) 


Level 


Conceptual primitives (Concept) 


Level 


alarm 


1 


simplexStop 


3 


beam 


3 


switchAlarm 


2 


cause 


1 


supervisedEquipement 


2 


efficiency Alarm 


3 


switch 


3 


incident 


1 






Conceptual primitives (Property) 


Type 


Conceptual primitives (Property) 


Type 


toBeDisclosedBy 


B 


toBeAboutBeam 


S 


toBeAbout 


B 


toBeAboutSwitch 


S 



Among the new CPs, some specialise already existing concepts, for example 
’’duplexStop” is kind of ’’incident” (figure 3). These primitives are modelled as 
specialising concepts. Their structural nature is structural, and their linguistic 
nature is terminological or pre-terminological depending on the fact that the 
primitive corresponds more or less to a domain term. The description of these 
primitives lead to specialise some properties. Here, ’’duplexStop” is disclosed by 
three types of alarms that are modelled (figure 3) by three specialisations of 
’’toBeDisclosedBy” . 

When some properties are shared by more than one concept, the knowledge 
engineer may add a grouping concept, like ’’beam Alarm” (figure 4) which is 
added with the couple (Statel, (grouping, not terminological)). Indeed, the label 
of ’’beamAlarm” concept does appear neither like a term, nor like a complex 
expression in the documents. The final modelling gives: 

1. the three properties ’’toBeDisclosedBy” are properties of the type (simple, specia- 
lised) with a terminological nature, 

2. concept ’’duplexStop” is Statel with nature (structural, terminological), 

3. concepts ’’overloading”, ” nullEfficiency Alarm” and ” simplexAlarm” are Stated with 
nature (structural, terminological). 

3.3 Representation Phase 

The representation is the translation of the modelling schemata into an object 
formalism like CG or like DL, for which some general rules are provided: 

1. The translation of a concept must be clearly defined into the formalism. It is 

not obvious at all that a direct translation would be possible even if the formalism 
shelters a primitive called concept. This concerns in particular the TopConcept. 

2. The translation of basic properties must also receive a properly defined representa- 
tion, and it is necessary to tell whether their translation can modify the description 
of the concepts that use it. 

3. The specialisation of properties must then be defined in the formalism and here 
again, it must be clear whether they may entail modifications of some concept 
descriptions or of some property descriptions. 

4. Finally, case by case, each calculated property should be represented. The corre- 
sponding computation has to be represented by special-purpose operators, inferen- 
ces rules or algorithms. Their translation is generally the most difficult problem. 
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We have shown in [7] that a chain of binary properties can sometimes be translated 
only into an inference mechanism. 

These general guidelines have to be made explicit for each target formalism, in 
a way detailed in [6] . 

4 Conclusion 

aims to facilitate the representation of domain ontology in a formalism 
like DL and CG. Mda,,; satisfies the needs of smoothness and legibility of the 
modelling and offers verification facilities without too rigorous semantic con- 
straints. The language is based on a method for acquiring knowledge from texts, 
which aims to keep the link between words in text and CPs in model so that 
understand and maintain the model and its formalisation would be easier. 

We have illustrated the modelling steps from texts to a semi-formal termi- 
nological ontology in with examples taken from an industrial application. 

We have presented some translation rules from the semi-formal ontology to a 
formal one in CG and DL. 
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Abstract. This paper presents the idea that the life cycle of an ontology is 
highly impacted as a result of the process of reusing it for building another 
ontology. One of the more important results of the experiment presented is how 
the different activities to be carried out during the development of a specific 
ontology may involve performing other types of activities on other ontologies 
already built or under construction. We identify in that paper new intra- 
dependencies between activities carried out inside the same otology and inter- 
dependencies between activities carried out in different ontologies. The 
interrelation between life cycles of several ontologies provokes that integration 
has to be approached globally rather than as a mere integration of out 
implementation. 



1 Introduction 

A lot of ontologies have been developed in recent years in different domains and for 
all sorts of applications. Many of these ontologies were built from scratch, that is, 
without reusing definitions from other existing ontologies. Furthermore, the reuse of 
other ontologies has been confined to the implementation phase, and the most 
commonly used software environments today [2], [3], [13] admit integration of code. 
Additionally, there is hardly any information or documentation describing the 
development process followed to build the ontologies. In other words, the community 
was more interested in the end product than providing information about the Ontology 
Development Process (ODP), that is, the activities carried out when building 
ontologies in a given domain. As consequence of this situation, not many ontology 
development methodologies have been developed to date. 

Uschold and King’s methodology [14] and Griininger and Fox [10] methodologies 
start by setting out the need and purpose for building the ontology. Having acquired a 
significant amount of domain knowledge, they propose direct codification in special- 
purpose ontology implementation languages. The main drawbacks of this approach 
are: a) conceptual models are implicit in the implementation codes; b) Domain 
experts and human end users have no undesrtanding of formal ontologies codified in 
ontology languages; c) direct coding of the knowledge acquisition result is too abrupt 
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a step, especially for complex ontologies. So, ontologists should think 
simoultaneously on the analysis of the knowledge and the technology to implement 
such knowledge; and d) ontology-developer preferences in a given languages 
condition the notation and implementation of the acquired knowledge. 

Methontology [4], [5], however, provides guidelines for specifying ontologies at 
the knowledge level as a conceptualisation that is independent of the ontology 
implementation languages. Methontology includes the definition of the ODP, which is 
based on the IEEE Standard 1074-1995 [11] for software development process; a life 
cycle based on evolving prototypes [5]; and the techniques that encompasses the 
activities identified in the ODP. Three kind of activities are identified in 
Methontology are [5]: Project Management Activities include: Planning, Control and 
Quality Assurance; Development-Oriented Activities include: Specification, 

Conceptualization, Formalization, Implementation and Maintenance; and Support 
Activities include: Knowledge Acquisition, Integration, Evaluation [8], 

Documentation and Configuration Management. The ontology life cycle identifies the 
set of stages through which the ontology moves during its life time, describes what 
activities are to be performed in each stage and how the activities are related (relation 
of precedence, return, etc.). 

ODE [4] is an environment that gives technical support to Methontology. 
Ontologies can be conceptualised in ODE using tables and graphs. Ontologies are also 
evaluated at the conceptual level, and the translators generate the computable code. 
Thus, domain experts can use this approach to conceptualise new ontologies and 
validate domain ontologies, leading to cuts in the time spent on and resources 
invested in the knowledge acquisition and evaluation activities. 

With the purpose of identifying new activities and obtaining new techniques, we 
have developed ontologies in different domains and with different representation 
needs. One of the more interesting ontologies, from the viewpoint of the 
methodological results, is the Monatomic Ions (MI) ontology. During its 
development, not only intra-dependencies inside the activities of its ODP were found, 
but also inter-dependencies between the MI ontology and activities in some of the 
ontologies reused by the MI ontology. By intra-dependences we refer to the 
relationships between activities carried out inside the same ontology, for example, the 
relationship between knowledge acquisition and conceptualisation in Monatomic 
Ions. That is, intra-dependences define the ontology life cycle. By inter-dependences 
we refer to the relationships between activities carried out in different ontologies. For 
example, the MI development involved the performance of reengineering, merge, 
evaluation and configuration management on other ontologies, concretely, standard- 
units (SU) and chemical-elements (CE) (which were existing ontologies). In this 
paper, we describe some results about intra-dependencies, but our attention is mainly 
focused in inter-dependencies. 



2 Need of Environmental Ontologies 

Experts in several domains, including biology, geology, chemistry, law, computing, 
etc., work in the field of the environmental sciences. Each expert uses a vocabulary 
related to one of the areas of this science, and there is neither a common terminology 
nor any standard to support the accurate use of each term. 
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There are many potential ontologies in that domain, but we have centred on 
environmental pollutants. An ontology of this kind must include the methods for 
detecting all the pollutant components in several media (water, soil, air, etc.) and the 
maximum permitted concentration of these components, taking into account the 
legislation (European and Spanish) in force. The components of pollutants are ionic. 
Therefore, ions are the primary entities to be taken into account, as they are indicators 
of environmental pollution, deterioration, etc. Background knowledge of the elements 
in their pure state and their properties, as well as the units of measure of some 
properties, are needed to represent knowledge on ionic concentrations. The ontology 
of pollutants aims to output a unified, complete and consistent terminology that can 
be used precisely, non-ambiguously and consistently in environmental applications 
that employ the maximum permitted concentration to detect alterations in the above- 
mentioned media. 



3 Monatomic Ions Ontology Development Process 

The MI ontology was developed within the Methontology framework and using ODE. 
Methontology proposes that the ontology be specified after having started knowledge 
acquisition. Fig. 1 presents in continuous line the intradependencies between the 
activities of the MI ontology. While knowledge is being acquired, the ontology 
developer builds the conceptual model, integrates the selected ontologies, evaluate the 
ontology under development, as well as generate the associated documentation. Note 
that many of these activities take place at the same time. Having completed the 
conceptualisation, the system would be formalised and implemented. In our 
framework ontologies are not formalised, as ODE has a module that maps the 
conceptual model to a computable model using its translators to Ontolingua, OCML 
and Flogic. 

Related to the interdependencies between the activities of different ontologies (see 
discontinuous lines at Fig. 1), they emerged at the specification and integration 
activities of the monatomic ion ontology. First, at the specification of the MI 
ontology, we looked for candidate ontologies at the Ontolingua Server, at the Cyc 
server and ODE. Then, we made a preliminary evaluation the content and suitability 
of the candidate ontologies, and we selected the Ontolingua ontologies, which are 
more suitable for our purposes. 

The second interdependency emerged during the MI ontology integration activity. 
The selected ontologies (Standard Units and Chemical Elements) (SU and CE) were 
reviewed in depth to assure their correctness and completeness before their integration 
in the MI ontology. We performed reengineering of SU, and merge, evaluation and 
configuration management on CE. The aim behind this was to assure that these 
ontologies provided a solid basis on which to incrementally develop new ontologies. 
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3.1 Requirements Specification 

The purpose of the specification phase is to output a document that includes the 
purpose, level of formality and scope of the ontology, including other significant 
information. The starting point of the MI ontology are the ions, both anionic and 
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Fig. 1. Inter and intra dependencies between activities of the Monatomic Ions OOP 



cationic, addressed from the viewpoint of inorganic chemistry and, also, analyzed 
with a view of standardization in the soil and waterfields within the physical 
environment and in terms of human health. From the environmental viewpoint, the 
monatonic ions detected in the physical variables -water, soil and air- are defined, 
specifying the methods of detection and maximum permitted concentrations. 
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It is important to mention here that at the requirements specification phase of the 

MI ontology we started the integration process with other ontologies. The initial 

activities we performed were: 

• To find and locate candidate ontologies to be reused. We located the SU ontology 
[9], which defines the basic units of measure at the Ontolingua Server, and CE [4], 
which defines the chemical elements of the periodic system in their pure state, at 
ODE and its Ontolingua code at the Ontolingua Server. At the Cyc server, we 
found some units of measure and chemical entities (atom, ion, molecule and 
radical). 

• To inspect the content and granularity of the candidate ontologies. The SU 
ontology at the Ontolingua Server includes for each unit: a natural language 
definition, its physical quantity and factors of conversion to other units of the same 
quantity, whereas the Cyc ontology included only a natural language definition. 

• We selected the ODE and Ontolingua Server ontologies, and we used Cyc 
ontologies for reference purposes. Fig. 2 shows how all these ontologies, and the 
ontologies included by the SU and CE ontologies are related at the Ontolingua 
Server. Ontologies at the top include the ontologies at the bottom. 

• Ontologits did a preliminar evaluation of SU from the knowledge representation 
point of view. As described in [7], several problems were found at the SU ontology 



Environmental-Pollit ant s 



Monatomic-Ions 




Polyatomic-Ions 



Chanical-Elaiient s 

f 

Standard-Units 



St andard-Dimensimir'''^ 



Physical-Quantities 



A 



KIF-Numbers ' 



Fig. 2. Relationships between the ontologies 



and CE. The most important problem in SU was the lack of taxonomic 
organization since all the instances were of the root class. The review process in 
CE showed that different versions of the ontology needed to be merged to output a 
new unified and corrected ontology with which could be extended before being 
included in the MI ontology. 

• Simoultaneously with the previous evaluation, domain experts also did a 
preliminar evaluation of CE ontology since its conceptual model was available in 
ODE and was understandable for the experts. However, we have postponed SU 
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domain experts evaluation since domain experts were unable to understand 
Ontolingua code. 

Thus, the need of the SU preliminar evaluation forces the SU reverse engineering 
for obtaining its conceptual model, and the presence of several versions on CE forces 
its merge, evaluation and configuration management. 



3.2 Knowledge Acquisition 

Knowledge acquisition was performed using techniques recommended in Knowledge 
Engineering for developing Knowledge-Based Systems. So, two open interviews 
(which output a preliminary classification of ions) and six structured interviews (to 
get the final classification of ions, concepts, attributes, etc.) were held and informal 
text analysis and table analysis was conducted. 



3.3 Conceptualisation 

As we have already said, the conceptualisation was performed, following 
Methontology and using ODE. The Methontology intermediate representations used 
were: glossary of terms, concept classification trees, relationship diagram, table of 
relationships, concept dictionary, class attribute tables, logical axiom tables, and 
constants table. Other intermediate representations, like instance attribute tables, 
formula tables and instance tables, have not been used, because this ontology does not 
have any instance. Of all the representations, the Concept Classification Tree (CCT) 
deserves a special mention. Only one CCT was built from the concepts identified in 
the GT, which means that we have only one ontology. 

Four criteria were applied when building the CCT. First, the chosen model must be 
easily understandable and must accurately reflect the knowledge specified by the 
experts. Second, the ontology must be easily extendible. Third, the ontology must be 
easily integrated with other ontologies. Fourth, it must be possible to select only part 
of the ontology for use in other ontologies or applications. 

According to these objectives, ions can evidently be studied from more than one 
viewpoint: from the general viewpoint, which is concerned with specifying the name 
and symbol of the ion among other properties; from the chemical viewpoint, which is 
concerned with defining chemical properties; from the viewpoint of the physical 
environment. Any taxonomy built should enable an ion defined from the chemical 
viewpoint to inherit the name and the symbol that are defined for that ion from the 
general viewpoint. The CCT designed takes into account all these considerations. As 
shown in Fig. 3, the CCT is actually a graph. The benefits of this classification are: 

• As the ions are defined from more than one viewpoint, it is possible to reuse part 
of the knowledge gathered by the ontology. Thus, if an application is defined 
strictly in the domain of chemistry, it is possible to reuse only the knowledge 
present in the Chemical Ion subhierarchy. 

• If the water pollutant ions are required, the water ions will be selected (e.g.. 
Cadmium (-GI) in Water), as well as all the classes that link each ion to the 
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hierarchy root class. Note that apart from classes related to environmental ions, 
classes such as Cadmium (+11) and General Ion will also be included, thus making 
it possible to access properties which are associated with the ion in its pure state, 
irrespective of the viewpoint used. 

• All the knowledge can be reused if it is integrated into a higher level ontology. 

• The ontology can be easily extended to other media and variables, such as the 
human or social environment. 

• New definitions of ions can be entered from any viewpoint. For example, if a future 
directive were to include any additional ion as a possible pollutant of the physical 
medium water, it would be easy to define this new ion and enter it as new 
knowledge into the ontology. 

It is just as straightforward to enter new ions from the chemical viewpoint, 
where all you have to do is to correctly select the group to which the above ion 
belongs and get the attribute values identified for the other ions from any of the 
referenced knowledge sources. 

• By using inheritance, an ion in water has the properties defined for the ion and will 
inherit the properties defined for the above ion in the physical medium and from 
the general viewpoint. 

• New properties can be easily included if required by any individual application. 

The concept classification tree was verified to assure that: (a) No concepts are 
repeated and there are no synonyms, which rules out redundancies in the conceptual 
model, (b) There are no cycles [6] among concepts, (c) There are no isolated subtrees 
for concepts that should be related, and (d) All the concepts represented in the tree are 
in the glossary of terms and vice versa. 



3.4 Formalisation and Implementation 

No formalisation was performed, as ODE has a module that maps the conceptual 
model to a computable model automatically using translators. 
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3.5 Integration 

The objective of integration is to build an ontology by reusing definitions of 
knowledge present in other ontologies. Before they were reused, the following 
activities were carried out: reengineering on SU, and merge, evaluation and 
configuration management on CE. It is mainly in this integration activity where the 
main and stronger interdependencies appear. These interdependencies are shown in 
Fig. 1. As we said before, the main reason for reengineering the SU ontology were: 
(a) domain experts and human end users have no understanding of formal ontologies 
codified in ontology languages. So, they can not validate the content of these 
ontologies; and (b) the lack of taxonomic organisation and conversion factor between 
some units of the SU ontology. Here, we also present the process for reviewing CE to 
assure their suitability. 



3.5.1 Ontological Reengineering on Standard Units 

Ontological reengineering [7] is the process of retrieving and mapping a conceptual 
model of an implemented ontology to another, more suitable conceptual model, which 
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is re-implemented. The method for reengineering ontologies is presented in Fig. 4 and 
adapts Chikofsky’s software reengineering schema [1] to the ontology domain. Three 
main activities were identified: reverse engineering, restructuring and forward 
engineering. Fig. 5 pictures in detail an organizational chart showing the activities 
performed during the reengineering process and the documents generated in each 
step. The goal of the processes described at Fig. 4 are: 

Step 1. Reverse Engineering. Its objetive is to output a possible conceptual model on 
the basis of the code in which the ontology is implemented. SU was analyzed on the 
basis of its Ontolingua implementation. 

Step 2. Restructuring. The goal of restructuring is to reorganized this initial 
conceptual model into a new conceptual model which is built bearing in mind the use 
of the restructured ontology by the ontology/application that reuses it. As presented in 
[7], the restructuring activity contains two phases: analysis and synthesis. The 
analysis phase includes evaluation (steps 2 to 5 of Fig. 5), whose general aim is to 
evaluate the ontology, that is, to check that the hierarchy of the ontology and its 
classes, instances, relations and functions are complete, consistent (there are no 
contradictions), concise (there are no explicit and implicit redundancies) and 
syntactically correct. The synthesis phase (step 6 of Fig. 5) seeks to correct the 
ontology after the analysis phase and document any changes made. So, activities 
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related with configuration management arise in that context, which goal is to keep a 
record of ontology evolution and strict change control. 

SU was restructured bearing in mind its future use by the CE and MI ontologies. 
Since the reverse engineering phase provided a possible conceptual model, domain 
experts can now validate the SU ontology. The evaluation they performed at the 
conceptual model were if all the units to be used at the MI ontology were already 
defined at the SU ontology, as well as the factor conversions needed between the 




Fig. 5. Ontological reenginering activities 



units. It is important to stress here that this restructuring is guided by the ontology that 
is to reuse the knowledge, which means that there is no way of assuring that the 
restructured ontology will be a hundred per cent valid for ontologies that reuse the 
restructured knowledge. 

Step 3. Forward Engineering. The objective of this step is to output a new 
implementation of the ontology on the basis of the new conceptual model. The 
implementation of the new conceptual model of SU was carried out using ODE 
translators. Note that after doing reengineering on SU, there exist two versions of that 
ontology, the old version at the Ontolingua Server, and the new version in ODE. 

Finally, to keep control of the changes made, we performed configuration 
management during the whole process. It is defined in software engineering as [12]: 
„Activity that is applied throughout the software engineering process for the 
following purposes: establish and maintain the integrity of the products generated. 
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evaluate and control the system changes and provide product visibility". Adapting the 
idea of configuration management from Software Engineering into the ontological 
engineering field, on the Methontology framework, we recommend the following 
activities: 

CM.l. IdentiUcation of the elements to be controlled. These elements include not 
only the documents related with the development of the ontology (requirement 
specification document, the sources used in Knowledge acquisition, conceptual 
models, implementation, integration documents, ontologies reused by this ontology, 
etc.) but also management activities (plan, quality assurance and control) and the 
software used to develop the ontology. To identify which are the elements to be 
controlled you can think what are your needs if the project stops and you re-start the 
project sometime later. We controlled the previous elements in CE and the 
mechanisms used to identify them was the concatenation of: the name of the 
ontology, the name of the element within the ontology, the version identifier, etc. 

CM. 2. Control of changes. Adapting Software Engineering steps to Ontological 
Engineering, and for each of the changes request, we propose that the Change control 
starts with a petition for change, followed by the classification and registration of 
request; approval or rejection of the change petition; report on how the change is to be 
made and what implications it has; order to make the change; making of change; 
performance of the change and certification that the change was made correctly. It 
ends when the result is reported to the person who proposed the change. 

CM. 3. Generation of status reports. We distinguish in that section the daily 
documentation generated about each configuration element and also general reports 
by demand (i.e., a report requested on the latest changes made to the ontology). 

For the purpose of assuring information about the evolution of the Standard-Units 
ontology, a rigorous change control has been performed throughout the restructuring 
phase. The goal is to have all the changes documented, detailing the changes made, 
their causes and effects. It is important to perform proficient change control of both 
definitions and taxonomies. In this manner, any ontologist who needs to use part of or 
the entire ontology can easily understand its evolution. Even if an ontology has not 
been fully developed, provided it is well documented, it could be finished off by 
another developer using the existing documentation. The configuration management 
documents can rule out incorrect decision making, if they state the courses of action 
to be taken at any time, and justify the choice of one rather than another. Change 
control also helps end users to determine which version of the ontology they require 
for their system or for the new ontology they are to develop. 

Consequently, although the reengineering activity and configuration management 
of the SU ontology would belong to the life cycle of that ontology, the MI integration 
activity forces the realisation of that activity on a "stable" ontology. Besides, although 
the SU reengineering process provokes the SU evaluation and configuration 
management, we stress that these activities make sense per se. For more information 
on the re-engineering process, see [7]. 




Ontology’s Crossed Life Cycles 75 




Fig. 6. Points where configuration elements are approve 



3.5.2 Review of Chemical-Elements (CE) 

CE is also a stable ontology whose conceptual model is available in ODE. It is also 
available at the Ontolingua Server. Again, the experts wanted to review the ontology 
before reusing it. The review process revealed that there were different versions of 
this ontology, which needed to be merged prior to any extension. The review process 
was divided into the three following activities (see Fig. 1): 

• Merging. Chemicals started to be developed in June 1995, and the first stable 
version was built in December 1996. New versions of this ontology have been 
created since then to be used in different ontologies. Therefore, it was necessary to 
group all the conceptual models into one, which includes all the improvements 
made to the ontology. 

• Evaluation. The knowledge present in the resulting conceptual model after 
merging was evaluated with the experts in order to assure that the knowledge was 
correct and complete, and to detect omissions. 

• Configuration Management. Configuration management was carried out 
according to the guidelines described previously to make this new version of CE 
easier to understand for users and also to keep records of all the versions of the CE 
ontology. 

Configuration management activities had a strong relationship with evaluation 
activities. There are two reasons. First, evaluation has to be run at least after each 
of the phases of the ontology development process, since configuration elements 
can be used as a basis in the following phases of the ontology development 
process. Second the changes performed as a consequence of the evaluation activity 
need to be controlled. Fig. 6 presents the baselines on the ontology development 
process. 

Again, although the merge, evaluation and configuration management activities 
belong to the life cycle of CE ontology, the MI integration activity forces the 
realisation of those activities on a "stable" ontology. 



3.6 Evaluation 

The MI ontology was evaluated by the experts throughout the entire life cycle and, 
especially, in the conceptualisation using ODE evaluation module. 
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3.7 Documentation 

Documentation has been carried out throughout the whole ODP. The previous 
activities output: a requirements specification document; a knowledge acquisition 
document; the conceptual model, composed of a set of intermediate representations; 
an integration document; the configuration management reports, and the evaluation 
document. 



4 Crossed Life Cycles 

In the previous section we have presented the main activities carried out during the 
development of the MI ontology, the order of execution of such activities as well as 
the interdependencies with other activities that were performed in other ontologies 
prior to their integration on the MI ontology. 

In that section we present the idea that when an ontology reuses definition of other 
ontologies, the ontology life cycle of the first crosses with the life cycle of the second 
and provokes some changes on its life cycle. 

The main intersections between the life cycles of the SU, CE and MI ontologies are 
shown in Fig. 7. Note that the SU ontology was built at the beginning of the last 
decade and, probably, several applications have already used its definitions. The SU 
ontology life cycle was "latent" or "hibernate". That is, since the SU ontology was 
built, nobody has changed its definitions at the Ontolingua Server and ontologies and 
applications reuse that ontology as it is. When we developed CE [4], we identified 
some units of measures that did not appear at SU, and we added them to the SU 
ontology at the Ontolingua Server. We updated that ontology with the new units but 
we did not performed big changes in its structure and on its content. Consequently, 
these updates could be seen as maintenance activities on the SU ontology. We can 
really say that the life cycle of the SU "wakes up" when SU is going to be reused on 
the MI ontology and the reengineering process over the SU ontology starts. At this 
point, the SU life cycle is alive since we modified its structure and its content. 

Another interesting observation in Fig. 7 is that the life cycle of the SU branches in 
two. So, two SU ontologies -the Ontology Server SU and the reengineered SU- were 
available after running a reengineering process on SU. The opposite occurs with CE, 
where several ontologies exist, each one with its life cycle, and they meet with the 
new life cycle of the merged CE ontology after the merging process. 

These confluences and forking of life cycles call for a global management of 
ontologies. We claim that, the configuration management of each ontology must not 
be carried out separately from the others in which are integrated. Configuration 
management must be global and simultaneously affect all the ontologies handled by 
the group. 
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Fig. 7. Crossed life cycles of Standard Units, Chemical and Monatomic Ions 



5 Conclusions 

In this paper we present how the different activities to be carried out during the 
development of a specific ontology may involve performing other types of activities 
on other ontologies already built or under construction. Such activities include: 
reengineering, merge, technical evaluation and configuration management. So, neither 
integration at the implementation level nor at the knowledge level is sufficient. There 
is also a need to unify ontology development management policies and to integrate 
products output throughout the development of ontologies whose development 
processes are interrelated. Therefore, the life cycle of an ontology should always be 
documented and accessible. 
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We have presented the intradependencies between the activities (specification, 
knowledge acquisition, conceptualization, formalization, integration, implementation, 
evaluation, documentation) of the MI ODP. We have also presented how the different 
activities to be performed during the development of a concrete ontology (i.e., 
specification and integration activities in MI) may involve performing other activities 
(reengineering, evaluation, configuration managemnent) on other ontologies already 
built (SU and CE ontologies). The idea to consider the activities on each ontology as 
separate and dependant life cycles helps to understand clearly the complementarity 
between knowledge reuse and knowledge modelling of domain specific knowledge. 
Below, an assessment is given of each activity performed, specifying the 
contributions made from the methodological viewpoint. Also, the results obtained in 
each of the following areas are evaluated: 

• Knowledge reuse. This paper presents a clear example of an ontology that reuses 
knowledge from other ontologies. In this case, the reuse and integration of 
ontologies led to the reengineering of SU and the merge, evaluation and 
configuration management of CE. 

• Ontology evaluation. Three ontologies were evaluated, each by means of a 
different process: 

a. Standard Units. It is done during the restructuring phase of the ontological 
reengineering process. 

b. Chemicals. This ontology passed three evaluations. The first was a technical 
judgement throughout its ODP, that is, when it was built [4]. The second was the 
evaluation after the merging process. The third is the assessment by the experts 
to determine the compliance with the new MI ontology. 

c. Monatomic Ions. The ontology was evaluated throughout the ODP to assure 
that: the requirements specification was met, the knowledge represented was 
comparable with reality, the content of the ontology was consistent, complete 
and concise, etc. 

• Configuration management. Configuration management was conducted on SU 
and CE as a supplementary activity to reengineering, merge and evaluation. It is 
important to control de changes because an ontology developer who needs to reuse 
that ontology (in full or in part) can easily understand its evolution. 

• Development of the MI ontology. The conceptual model finally developed, in 
which MI is studied from several viewpoints, assures that the definitions are 
independent of the end use of the ontology. For proving this with the experience, 
ontologies reusing MI are been developed at present. Additionally, this ontology 
can be totally or partially reused in other ontologies or applications. In fact, an 
important purpose that we have with the development of MI and other 
environmental ontologies is to prove that it is possible to build reusable and usable 
ontologies incrementaly. 

To refine the reengineering process showed in this paper, it should be desirable to 
apply this process to more complex ontologies than SU. However, MI is an ontology 
that has need several month of work, and its ODP has required not only development 
activities, but also management, control and support activities. Besides, for some 
activities (for example, evaluation), we had former experience based on the 
development of others ontologies. So, the more likely is that the most techniques and 
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processes showed in this paper will need a minor refinement for being applicable to 
other developments. 

We are scaling up the method making the necessary changes for adapting it to the 
development of other ontologies in the environmental field. Normally, when a new 
ontology is built, there are less modifications on the method than the necessary 
modifications for former ontologies, so there should be a moment in which the 
method is general enough to be applied to the development of a large quantity of 
ontologies. 
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Abstract. The interchange of ontologies across the World Wide Web (WWW) 
and the cooperation among heterogeneous agents placed on it is the main reason 
for the development of a new set of ontology specification languages, based on 
new web standards such as XML or RDF. These languages (SHOE, XOL, RDF, 
OIL, etc) aim to represent the knowledge contained in an ontology in a simple 
and human-readable way, as well as allow for the interchange of ontologies 
across the web. In this paper, we establish a common framework to compare the 
expressiveness and reasoning capabilities of „traditional“ ontology languages 
(Ontolingua, OKBC, OCML, FLogic, LOOM) and „web-based“ ontology 
languages, and conclude with the results of applying this framework to the 
selected languages. 



1 Introduction 

In the past years, a set of languages have been used for implementing ontologies. 
Ontolingua [6] is perhaps the most representative of all of them. Other languages have 
also been used for specifying ontologies: LOOM [16], OCML [17], FLogic [12], etc. 
Protocols such as OKBC[4] have been also developed to access KR systems. KR 
paradigms underlying these languages and protocols are diverse: frame-based, 
description logic, first (and second) order predicate calculus and object-oriented. 

In the recent years, new languages for the web have been created -XML [2], RDF 
[13] and RDF Schema [3]- and are still in a development phase. Other languages for 
the specification of ontologies, based on the previous ones, have also emerged: SHOE 
[15], XOL [11] and OIL [10]. Preliminary studies exist on the use of web-based 
languages for representing ontologies. In [9], an analysis is shown on the role of 
HTML, XML and RDF when providing semantics for documents on the Web. 

The purpose of this paper is to analyse the tradeoff between expressiveness {what 
can be said) and inference {what can be obtained from the information represented) 
in traditional and web-based ontology languages. In Section 2, we will present a 
framework for evaluating the expressiveness and inference mechanisms of ontology 
specification languages. Section 3 will describe both the so-called traditional ontology 
languages and the web-based ontology languages. As a conclusion, section 4 presents 
a discussion on the results of the study. 
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2 Evaluation Framework 

The goal of this section is to set up a framework for comparing the expressiveness and 
inference mechanisms of potential ontology languages. We use in our analysis the 
CommonKADS framework [18], which distinguishes between domain knowledge and 
inference knowledge. Figure 1 summarises the relationship between the KR 
components and the reasoning mechanisms of languages. 



2.1 Domain Knowledge 

The domain knowledge describes the main static information and knowledge objects 
in an application domain [18]. We identify the main kind of components used to 
describe domain knowledge in ontologies. Accordingly to Gruber [8], knowledge in 
ontologies can be specified using five kind of components: concepts, relations, 
functions, axioms and instances. Concepts in the ontology are usually organised in 
taxonomies. Sometimes the notion of ontology is somewhat diluted, in the sense that 
taxonomies are considered to be full ontologies [19]. Other components like 
procedures and rules are also identified in some ontology languages (i.e., OCML). For 
each one of the components outlined before (except for procedures, as it is very 
difficult to find common characteristics for them in all languages) we will select a set 
of features that we consider relevant. 



Concepts [18], also known as classes, are used in a broad sense. They can be abstract 
or concrete, elementary or composite, real or fictions. In short, a concept can be 
anything about which something is said, and, therefore, could also be the description 
of a task, function, action, strategy, reasoning process, etc. The following questions 
identify the expressiveness of a language when defining classes: 

• Is it possible to define metaclasses (classes as instances of other ones)? They are 

important in case that a KR ontology exists for the language. 

• Is it possible to define partitions (sets of disjoint classes)? 

• Does the language provide mechanisms to define slots/attributes? For example: 

• Local attributes. Attributes which belong to a specific concept. For instance, 
attribute age belongs to concept Person. 

• Instance attributes (template slots). Attributes whose value may be different 
for each instance of the concept. 

• Class attributes (own slots). Attributes whose value must be the same for all 
instances of the concept. 

• Polymorph attributes. Attributes (slots) with the same name and different 
behaviour for different concepts. For instance, the attribute author for concept 
Thesis is different from the attribute author for concept Book. Its type for Thesis 
is Student, and its type for Book is Person. 

• Does the language provide the following predefined facets for attributes? 

• Default slot value, which will be used to assign a value to the attribute in case 
there is no explicit value defined for it. 
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Fig. 1. Evaluation Framework 

• Type, which will be used to constrain the type of the attribute. 



• Cardinality constraints, which will be used to constrain the minimum and 
maximum number of values of the attribute. 

• Documentation, which could include a natural language definition for it. 

• Operational definition, which could include the definition or selection of a 
formula, a rule, etc to be used, for instance, when obtaining a value for that 
attribute. 

• May new facets be created for attributes? 



Taxonomies. They are widely used to organise ontological knowledge in the domain 
using generalisation/specialisation relationships through which simple/multiple 
inheritance could be applied. Since there exists some confusion regarding the 
primitives used to build taxonomies, we propose to analyse whether or not the 
following primitives (which are based on the definitions provided by the frame 
ontology at Ontolingua) are predefined in the languages. 

• Subclass of specialises general concepts in more specific concepts. 

• Disjoint decompositions define a partition as subclass of a class. The 
classification does not necessarily have to be complete (there may be instances of 
the parent class that are not included in any of the subclasses of the partition). 

• Exhaustive subclass decompositions define a partition as subclass of a class. The 
parent class is the union of all the classes that make up the partition. 

• Not subclass of may be used to state that a class is not a specialisation of another 
class. This kind of knowledge is usually represented using the denial of the 
subclass of primitive. 

Some languages have a formal semantics for those primitives, and others must 
define their semantics by using axioms or rules. 
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Relations [8] represent a type of interaction between concepts of the domain. They 
are formally defined as any subset of a product of n sets. First, we consider the 
relationship between relations and other components in the ontology. We will ask if 
concepts and attributes are considered, respectively, as unary and binary relations. 
Functions [8] are considered as a special kind of relations where the value of the last 
argument is unique for a list of values of the n-1 preceding arguments. 

Second, we focus on the arguments (both in relations and functions): 

• Is it possible to define arbitrary n-ary relations/functions? If this is not possible, 
which is the maximum number of arguments? 

• May the type of arguments be constrained? 

• Is it possible to define integrity constraints in order to check the correctness of 
the arguments’ value? 

• Is it possible to define operational definitions to infer values of arguments with 
procedures, formulas and rules, or to define its semantic using axioms or rules? 



Axioms [8] model sentences that are always true. They are included in an ontology 
for several purposes, such as constraining its information, verifying its correctness or 
deducting new information. We will focus on the next characteristics: 

• Does the language support building axioms in first order logic? 

• And second order logic axioms? 

• Are axioms defined as independent elements in the ontology (named axioms) or 
must they be included inside the definition of other elements, such as relations, 
concepts, etc? This feature improves readability and maintenance of ontologies. 



Instances/Individuals/Facts/Claims. All these terms are used to represent elements 
in the domain. Instances [8] represent elements of a given concept. Facts [17] 
represent a relation which holds between elements. Individnals [6] refer to any 
element in the domain which is not a class (both instances and facts). Claims [15] 
represent assertions of a fact by an instance. It is important to highlight the inclusion 
of claims, since people on internet can make whatever claims they want. Flence, 
agents shouldn’t interpret them as facts of knowledge, but as claims being made by a 
particular instance about itself or about other instances or data, which may prove to be 
inconsistent with others [15]. The following questions will be asked in this section: 

• Is it possible to define instances of concepts? 

• Is it possible to define instances of relations (facts)? 

• Does the language provide special mechanisms to define claims? 



Production rules. Production rules [16], which follow the structure If ... Then ..., are 
used to express sets of actions and heuristics which can be represented independently 
from the way they will be used. A set of questions will be asked about them: 

• Is it possible to define disjunctive and conjunctive premises? 

• May the chaining mechanism be defined declaratively? 

• Is it possible to define truth values or certainty values attached to the rule? 
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• May procedures be included in the consequent? They are commonly used to 
change the values of attributes of a concept, add information to the KB, etc. 

• Does the language support updates of the KB, performed by adding or removing 
facts or claims? 



2.2 Inference Mechanisms 

This dimension describes how the static structures represented in the domain 
knowledge can be used to carry out a reasoning process [18], There is a strong 
relationship between both dimensions, as the structures used for representing 
knowledge are the basis for the reasoning process, as seen in Figure 1. We analyse 
whether the language supports the following features or not: 

• Does the language provide an inference engine that reasons with the knowledge 
represented using the language? Is it sound? And complete? 

• Does the inference engine perform automatic classifications? 

• Does the inference engine deal with exceptions? Exceptions are considered when 
attribute Attribute 1 is defined for concept Cl and concept C2, being Cl subclass of 
C2 and we analyse whether the definition of Attribute 1 in concept Cl overrides the 
definition of Attribute 1 in concept C2 or not. 

• Is it possible to use monotonic, non-monotonic, simple and/or multiple 
inheritance? 

• Are procedures executable? 

• Do axioms perform any kind of constraint checking? 

• When reasoning with rules, does the language allow forward and backward 
chaining? 



3 Ontology Specification Languages 

In this section, we show an analysis of ontology specification languages which have 
been and are widely used by the ontology community (Ontolingua, OKBC, OCML, 
FLogic and LOOM), other languages created in the context of Internet, which are 
recommendations of the W3C (XML, RDF and RDFS) and, finally, other new 
languages for the specification of ontologies (XOL, SHOE and OIL). 



3.1 Traditional Ontology Specification Languages 



Ontolingua [6] is a language based on KIF [7] and on the Frame Ontology (FO) [6], 
and it is the ontology-building language used by the Ontolingua Server [6]. 

KIF (Knowledge Interchange Format) was developed to solve the problem of 
heterogeneity of languages for knowledge representation. It provides for the definition 
of objects, functions and relations. KIF has declarative semantics and it is based on 
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first-order predicate calculus, with a prefix notation. It also provides for the 
representation of meta-knowledge and non-monotonic reasoning rules. 

As KIF is an interchange format, it is tedious to use for specification of ontologies 
per se. The FO, built on top of KIF, is a knowledge representation ontology that 
allows an ontology to be specified following the paradigm of frames, providing terms 
such as class, instance, subclass-of, instance-of etc. The FO does not allow to express 
axioms; therefore, Ontolingua allows to include KIF expressions inside of definitions 
based on the FO. Summarizing, Ontolingua allows to build ontologies in any of the 
following three manners: (1) using exclusively the FO vocabulary (axioms cannot be 
represented); (2) using KIF expressions; (3) using both languages simultaneously. 

Currently, an inference engine is being developed for Ontolingua. The OKBC API 
must be used in case we want to develop a customized one. 



OKBC Protocol [4] is an acronym for Open Knowledge Base Connectivity, 
previously known as Generic Frame Protocol. It specifies a protocol (not a language). 
The protocol makes assumptions about the underlying KR system (frames), and it is 
complementary to language specifications developed to support knowledge sharing. 

The GFP Knowledge Model, which is the implicit representation formalism 
underlying OKBC, supports an object-centered representation of knowledge and 
provides a set of representational constructs commonly found in frame representation 
systems: constants, frames, slots, facets, classes, individuals and knowledge bases. 

It also defines a complete tell&ask interface for knowledge bases accessed using 
OKBC protocol, and procedures (with a Lisp-like syntax) in order to describe 
complex operations to perform in a knowledge base when accessing it over a network. 

Eventually it has been developed the OKBC-Ontology for Ontolingua, which is 
fully compatible with the OKBC protocol. 

In this study, when referring to OKBC we will mean the API, together with the 
maximum expressiveness permitted. 



OCML [17] stands for Operational Conceptual Modeling Language, and was 
originally developed in the context of the VITAL project. 

OCML is a frame-based language that provides mechanisms for expressing items 
such as relations, functions, rules (with backward and forward chaining), classes and 
instances. In order to make the execution of the language more efficient, it also adds 
some extra logical mechanisms for efficient reasoning, such as procedural 
attachments. A general tell&ask interface is also implemented, as a mechanism to 
assert facts and/or examine the contents of an OCML model. 

Several pragmatic considerations were taken into account in the development of 
OCML. One of them is the compatibility with standards, such as Ontolingua, so that 
OCML can be considered as a kind of „operational Ontolingua", providing theorem 
proving and function evaluation facilities for its constructs. 
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FLogic [12] is an acronym for Frame Logic. FLogic integrates frame-based 
languages and first-order predicate calculus. It accounts in a clean and declarative 
fashion for most of the structural aspects of object-oriented and frame-based 
languages, such as object identity, complex objects, inheritance, polymorphic types, 
query methods, encapsulation, and others. In a sense, FLogic stands in the same 
relationship to the object-oriented paradigm as classical predicate calculus stands to 
relational programming. 

FLogic has a model-theoretic semantics and a sound and complete resolution-based 
proof theory. 

Applications of FLogic go from object-oriented and deductive databases to 
ontologies, and it can be combined with other specialized logics (FliLog, Transaction 
Logic), to improve the reasoning with information in the ontologies. 



LOOM [16] is a high-level programming language and environment intended for use 
in constructing expert systems and other intelligent application programs. It is a 
descendent of the KL-ONE family and it is based in description logic, achieving a 
tight integration between rule-based and frame-based paradigms. 

LOOM supports a "description" language for modeling objects and relationships, 
and an „assertion“ language for specifying constraints on concepts and relations, and 
to assert facts about individuals. Procedural programming is supported through 
pattern-directed methods, while production-based and classification-based inference 
capabilities support a powerful deductive reasoning (in the form of an inference 
engine: the classifier). 

It is important to focus on the description logic approach to ontology modeling, 
which differs from the frame-based approach of the previously described languages. 
Definitions written using this approach try to exploit the existence of a powerful 
classifier in the language, specifying concepts by using a set of restrictions on them. 



3.2 Web Standards and Recommendations 



XML [2] stands for eXtended Markup Language deriving from SGML {Standard 
General Markup Language). It is being developed by the XML Working Group of the 
World Wide Web Consortium (W3C), and it is next to become a standard. 

As a language for the World Wide Web, its main advantages are: it is easy to parse, 
its syntax is well defined and it is human readable. There are also many software tools 
for parsing and manipulating XML. It allows users to define their own tags and 
attributes, define data structures (nesting them), extract data from documents and 
develop applications which test the structural validity of a XML document. 

When using XML as the basis for an ontology specification language, its main 
advantages are: 

• The definition of a common syntactic specification by means of a DTD {Document 
Type Definition). 

• Information coded in XML is easily readable for humans. 
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• It can be used to represent distributed knowledge across several web-pages, as it 
can be embedded in them. 

XML also presents some disadvantages which influence on ontology specification: 

• It is defined in order to allow the lack of structure of information inside XML tags. 
This makes it difficult to find the components of an ontology inside the document. 

• Standard tools are available for parsing and manipulating XML documents, but not 
for making inferences. These tools must be created in order to allow inferences 
with languages which are based on XML. 

XML itself has no special features for the specification of ontologies, as it just 
offers a simple but powerful way to specify a syntax for an ontology specification 
language (this is the reason why XML is not included in the comparison of section 5). 
Besides, it can be used for covering ontology exchange needs, exploiting the 
communication facilities of the WWW. 



RDF [13] stands for Resource Description Framework. It is being developed by the 
W3C for the creation of metadata describing Web resources. Examples of the use of 
RDF in ontological engineering may be analyzed in [1] and [20]. 

A strong relationship stands between RDF and XML. In fact, they are defined as 
complementary: one of the goals of RDF is to make it possible to specify semantics 
for data based on XML in a standardized, interoperable manner. The goal of RDF is 
to define a mechanism for describing resources that makes no assumptions about a 
particular application domain nor the structure of a document containing information. 

The data model of RDF (which is based in semantic networks) consists of three 
types: resources (subjects), entities that can be referred to by an address at the 
WWW; properties (predicates), which define specific aspects, characteristics, 
attributes or relations used to describe a resource; and statements (objects), which 
assign a value for a property in a specific resource. 



RDF Schema [3] (RDFS) is a declarative language used for the definition of RDF 
schemas. The RDFS data model (which is based on frames) provides mechanisms for 
defining the relationships between properties (attributes) and resources. Core classes 
are class, resource and property, hierarchies and type constraints can be defined (core 
properties are type, subclassOf subPropertyOf seeAlso and isDefinedBy). Some core 
constraints are also defined. 



3.3 Web-Based Ontology Specification Languages 



XOL. [11] stands for XML-Based Ontology Exchange Language. It was designed to 
provide a format for exchanging ontology definitions among a set of interested 
parties. Therefore, it is not intended to be used for the development of ontologies, but 
as an intermediate language for transferring ontologies among different database 
systems, ontology-development tools or application programs. 

XOL allows to define in a XML syntax a subset of OKBC, called OKBC-Lite. As 
OKBC defines a protocol for accessing frame-based representation systems, XOL 
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may be suitable for exchanging information between different systems, via the 
WWW. The main handicap is that frames (defined in OKBC) are excluded from this 
language, and only classes (and their hierarchies), slots and facets can be defined. 
Many XML editing tools are available which allow to generate XOL documents. 



SHOE [15] stands for Simple HTML Ontology Extension. It was developed first as an 
extension of HTML, with the aim of incorporating machine-readable semantic 
knowledge in HTML or other WWW documents. Recently, it has been adapted in 
order to be XML compliant. The intent of this language is to make it possible for 
agents to gather meaningful information about web pages and documents, improving 
search mechanisms and knowledge-gathering. The two-phase process to achieve it 
consists of: (1) defining an ontology describing valid classifications of objects and 
valid relationship between them; (2) aimotating HTML pages to describe themselves, 
other pages, etc. 

In SHOE, an ontology is an ISA hierarchy of classes (called categories), plus a set 
of atomic relations between them, and inferential rules in the form of simplified horn 
clauses. Therefore, classes, relations and inferential rules can be defined. An 
important feature included in SHOE is the ability to make claims about information, 
as discussed in section 2. 



OIL [10], Ontology Interchange Language, is a proposal for a joint standard for 
describing and exchanging ontologies. It is still in an early development phase, and 
has been designed to provide most of the modelling primitives commonly used in 
frame-based and description logic ontologies (it is based on existing proposals, such 
as OKBC , XOL and RDF), with a simple, clean and well defined semantics, and an 
automated reasoning support. 

In OIL, an ontology is a structure made up of several components, organized in three 
layers: the object level (which deals with instances), the first meta level or ontology 
definition (which contains the ontology definitions) and the second meta level or 
ontology container (which contains information about features of the ontology, such 
as its author). Concepts, relations and functions and axioms can be defined in OIL. 
The syntax of instances, rules and axioms has not yet been defined. 



4 Results and Comparison of Languages 

The results of applying the evaluation framework described in section 2 are presented 
in this section. It is worth mentioning that a common evaluation framework has been 
used for different knowledge representation languages (and different knowledge 
representation paradigms, such as frame-based, description logic and object-centered), 
and that the results have been achieved taking into account the experience of coding, 
in all the selected languages, an ontology for electronic commerce, which is not 
shown here due to the lack of space. 

The trade-off between the degree of expressiveness and the inference engine of a 
language (the more expressive, the less inference capabilities) makes it difficult to 
establish a scoring of languages. Moreover, we claim that different needs in KR exist 
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nowadays for applications, and some languages are more suitable than others for the 
specific needs of a given application. 

When developing domain ontologies for an application, it is not only necessary to 
study the KR and reasoning needs for the application, but also the KR and reasoning 
capabilities provided by the languages. This framework will avoid the developer of 
ontologies taking blind decisions on the selection of the ontology language(s) to use. 

Information in tables of the next sections will be filled using ‘+’ to indicate that it 
is a supported feature in the language, for non supported features, ‘+/-’ for non 
supported features, but could manage to support it by doing something, ‘?’ when no 
information is available and ‘N.D.’ for features which are not restricted, but could be 
implemented in order to support them. The contents of tables represent the present 
situation of languages' and may change because of the evolution of them. 



4.1 Domain Knowledge 

Table 1 shows at first glance the main components of the ontology specification 
languages selected for this study. 

Concepts, n-ary relations and instances can be defined easily in almost all 
languages. In OKBC and FLogic, which are frame-based languages, relations can be 
represented by using frames, but not as special elements provided by the language. In 
OKBC, axioms are only supported in the tell&ask part of the API, although neither 
deductive nor storage guarantees are made for all OKBC implementations. 



Table 1. Definition of the main components of domain knowledge 





Onto 


OKBC 


OCML 


LOO 

M 


FLogi 

c 


XOL 


SHOE 


RDF(S 

) 


OIL 


Concepts 


+ 


+ 


+ 


+ 


+ 


+ 


+ 


+ 


+ 


n-ary relations 


+ 


+/- 


+ 


+ 


+/- 


- 


+ 


+ 


+ 


Functions 


+ 


+/- 


+ 


+ 


+/- 


- 


- 


- 


+ 


Procedures 


+ 


+ 


+ 


+ 


- 


- 


- 


- 


- 


Instances 


+ 


+ 


+ 


+ 


+ 


+ 


+ 


+ 


ND 


Axioms 


+ 


+/- 


+ 


+ 


+ 


- 


- 


- 


ND 


Production 

Rules 


- 


- 


+ 


+ 


- 


“ 


- 


“ 


ND 


Formal semantics 


+ 


+ 


+ 


+ 


+ 


+ 


- 


- 


- 



Functions, procedures and axioms cannot be defined using web-based languages, 
except for some restricted forms of axioms, such as deductive rules, which are 
definable in SHOE. 



’ ’Onto’ will be used to refer to Ontolingua. RDF(S) is the acronym used to refer to the 
combination of RDF and RDFS. 
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It is worth mentioning that procedures are only definable in Lisp-based languages, 
and production rules are just definable in OCML and LOOM. 

An additional row has been added to the table, analysing the presence of a formal 
semantics: some web-based languages, such as SHOE, RDF(S) and OIL lack of it, 
whereas traditional languages and XOL provide it. 



Concepts. Table 2 summarizes the most important features to be analyzed when 
describing concepts in an ontology. It is divided in 4 sections: metaclasses, partitions, 
definition of attributes and definitions of properties of attributes (facets). 



Table 2. Definition of concepts 



CONCEPTS 


Ont 

0 


OKBC 


OCML 


LOOM 


FLogie 


XOL 


SHOE 


RDF(S) 


OI 

L 


Metaclasses 


+ 


+ 


+ 


+ 


+ 


+ 


- 


+ 


- 


Partitions 


+ 


- 


- 


+ 


- 


- 


- 


- 


- 


ATTRIBUTES 




















Template 
(instance attrs) 


+ 


+ 


+ 


+ 


+ 


+ 


+ 


+ 


+ 


Own (class attrs.) 


+ 


+ 


+ 


+ 


+ 


+ 


- 


+ 


+/- 


Polymorphic 


+ 


+ 


+ 


+ 


+ 


- 


- 


- 


+ 


Local scope 


+ 


+ 


+ 


+ 


+ 


+ 


+ 


+ 


+ 


EACETS 




















Dcfanit slot valne 


- 


+ 


+ 


+ 


+ 


+ 


- 


- 


- 


Type constraint 


+ 


+ 


+ 


+ 


+ 


+ 


+ 


+ 


+ 


Cardinality 

constraints 


+ 


+ 


+ 


+ 


+/- 


+ 


- 


- 


+ 


Documentation 


+ 


+ 


+ 


+ 


- 


+ 


+ 


- 


+ 


Procedural 

knowledge 


- 


- 


+ 


+ 


- 


- 


" 






Adding new 
facets 


+ 


-H 


- 


+ 


- 


- 


- 


- 


- 



Only SHOE and OIL do not allow to define metaclasses, and partitions can only be 
defined in Ontolingua and LOOM. 

Instance attributes and type constraints for attributes can be defined using any of 
the chosen languages. The results of the rest of the values depend on the languages, 
although a glance at the table shows us that traditional ontology languages allow us, 
again, to define more features than web-based languages. 

Procedural knowledge inside the definition of attributes is only supported by 
OCML and LOOM, due to their operational behavior. It must be included in the 
definition of the OCML's attributes by means of special keywords, such as :prove-by 
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or :lisp-fun, not as simple facets, or in the definition of the LOOM’s attributes by 
means of keywords such as :sufficient, :is, :is-primitive or umplies. 

FLogic just allows to define the maximum cardinality for slots as 1 or N, while the 
minimum cardinality is always set to 0. 



Table 3. Definition of taxonomies 



TAXONOMIES 


Onto 


OKB 

C 


OCM 

L 


LOO 

M 


FLogi 

c 


XOL 


SHOE 


RDE( 

S) 


OIL 


Subclass of 


+ 


+ 


+ 


+ 


+ 


+ 


+ 


+ 


+ 


Exhaustive subclass 
partitions 


+ 


- 


+/- 


+ 


+/- 


- 


- 


- 


- 


Disjoint 

Decompositions 


+ 


- 


+/- 


+ 


+/- 


- 


- 


- 


+/- 


Not subclass of 


+/- 


- 


- 


+/- 


- 


- 


- 


- 


+ 



Taxonomies. When defining taxonomies, there is just one primitive predefined in all 
languages and correctly handled by them: subclass of. Ontolingua and LOOM are the 
only languages which have the rest of primitives (except for not subclass of, which 
must be declared using the denial of primitve subclass-of). These primitives can be 
defined as relations in the rest of languages, but as a consequence, there is no special 
treatment for them. In FLogic, axioms must be defined in order to provide the 
semantics for them. OIL allows to define the primitive not subclass-of, hence it is also 
possible to define disjoint decompositions. 



Relations and Functions. Relations are very important components in an ontology 
(hence they are supported by almost all the ontology languages), but not every 
desirable characteristic of relations is implemented in all languages. Functions are not 
included in some languages. 



Table 4. Definition of relations and functions 



RELATIONS 

FUNCTIONS 


Onto 


OKBC 


OCML 


LOOM 


FLogic 


XOL 


SHOE 


RDF(S) 


OIL 


Functions as 
relations 


+ 


+ 


- 


+ 


+ 




- 




+ 


Concepts: unary 
rels. 


+ 


+ 


+ 


+ 


- 




+ 




+ 


Slots: binary rels. 


+ 


+ 


+ 


+ 


- 


+ 


+ 


+ 


+ 


n-ary rels./functs. 


+ 


+/- 


+ 


+ 


+/- 


- 


+ 


+ 


+/- 


Type constraints 


+ 


+ 


+ 


+ 


+ 


- 


+ 


+ 


+ 


Integrity 

constraints 


+ 


+ 


+ 


+ 


+ 


- 


- 


- 


- 


Operational defs. 


- 


- 


+ 


+ 


+ 


- 


- 


- 


- 
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Many languages represent concepts as unary relations. Attributes are usually 
considered as binary relations, except for FLogic, where they are considered as 
ternary ones. 

Great semantic differences are found when analysing the role that functions play in 
different languages. Some languages, such as KIF (and consequently, Ontolingua), 
consider functions as a special case of relations in which the n"’ element of the relation 
is unique for the n-1 preceding elements. LOOM consider functions as relations 
where the result can be calculated given the domain arguments. In OCML, functions 
are considered as modelling elements which play a role which is completely different 
to the one of relations. In FLogic, functions are considered as methods which are 
defined inside a concept. Their value is calculated by using a deductive rule 
associated to the method previously declared. 

FLogic, OKBC, RDF(S) and OIL cannot define n-ary relations directly. They must 
define them as associative classes or by means of several binary relations. 

All languages allow the definition of type constraints for arguments, and the main 
differences among traditional and web-based ontology languages lay on the definition 
of integrity constraints (the last ones don’t allow to define them). 

The last comments are on operational definitions for relations: just OCML, LOOM 
and FLogic allow to define operations inside relations, although there is a difference 
between them: while LOOM provides operational definitions just for an inferential 
purpose, OCML also provides non-operational definitions which can be used for 
representational purposes [17]. In FLogic, this kind of operations must be defined by 
using axioms, which are defined apart. Ontolingua does not support user-defined Lisp 
lambda bodies for relations, but it has certain relations that have procedural 
attachments which are activated by the tell&ask interface (for instance, asking (+3 2 
?x) will reply with a single binding of 5 for ?x). 



Instances. Instances of concepts and of relations (facts) are supported by all the 
languages. Claims, however, are just allowed in some of the web-based ontology 
languages. This is due to the fact that the management of information which comes 
from different sources is an intrinsic characteristic of the web environment and so 
these languages have specialised ways to treat this information. 



Table 5. Definition of instances 



INSTANCES 


Onto 


OKBC 


OCML 


LOOM 


FLogic 


XOL 


SHOE 


RDF(S) 


OIL 


Instances of 
concepts 


+ 


+ 


+ 


+ 


+ 


+ 


+ 


+ 


ND 


Facts 


+ 


+ 


+ 


+ 


+ 


+ 


+ 


+ 


ND 


Claims 


- 


- 


- 


- 


- 


- 


+ 


+ 


ND 
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Axioms. This is a good measure of expressiveness. The richest the axioms defined, 
the more expressive the language is. Ontolingua allows the definition of first-order 
and second-order logic axioms. OCML and FLogic also allow to define first-order 
logic axioms independently of the rest of components of the ontology. 

LOOM just allows to define first-order logic axioms inside the definitions of 
relations, concepts and functions. 

The rest of languages, except for XOL, only allow restricted types of axioms. So, 
OKBC just supports a subset of the axioms which can be represented with KIF (and 
they must be included as a frame or by using the tell&ask interface), and SHOE just 
allows to define deductive rules. In OIL, the syntax of axioms has not yet been 
defined, while in RDF(S) several studies are currently trying to specify the syntax and 
semantics for the most commonly used axioms. 



Table 6. Definition of axioms 



AXIOMS 


Onto 


OKBC 


OCML 


LOOM 


FLogie 


XOL 


SHOE 


RDF(S) 


OIL 


L'-order logic 


+ 


+/- 


+ 


+ 


+ 


- 


+/- 


+/- 


ND 


2”'* order logic 


+ 


+/- 


- 


- 


- 


- 


- 


- 


- 


Named axioms 


+ 


+ 


+ 


- 


- 


- 


- 


- 


- 



Production rules. Production rules are components of an ontology in OCML and 
LOOM. LOOM distinguishes between purely deductive rules and side-effecting, 
procedural rules (production rules). OCML makes the same distinction, defining 
„backward“ and „forward“ ones. Therefore, OCML and LOOM allow to define the 
chaining when performing the reasoning with knowledge defined in the ontology. 

As far as OIL is concerned, rules are just a weak form of general inclusion axioms. 

Finally, SHOE does not allow to define production rules, but inference rules, as 
stated in the previous section. 



Table 7. Definition of mles 



PRODUCTION 

RULES 


Onto 


OKBC 


OCML 


LOOM 


FLogie 


XOL 


SHOE 


RDF(S) 


OIL 


PREMISES 




















Conjunctive 


- 


- 


+ 


+ 


- 


- 


- 


- 


ND 


Disjunetive 


- 


- 


+ 


+ 


- 


- 


- 


- 


ND 


CONSEQUENT 




















Truth values 


- 


- 


- 


- 


- 


- 


- 


- 


ND 


Exeeution of 
procedures 


- 


- 


+/- 


+ 


- 


- 


- 


- 


ND 


Updating the KB 


- 


- 


+ 


+ 


- 


- 


- 


- 


ND 
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4.2 Reasoning 

A clear distinction between KR and reasoning exists for all languages, except for 
OCML. For instance, Ontolingua is maybe the most expressive of all the languages 
chosen for this study, but there is no inference engine implemented for it. OCML 
allows to define some features concerning reasoning inside representational elements 
(for instance, rules can be defined as backward rules or forward ones, so that the 
chaining is explicitly defined). 

Just FLogic and OIL inference engines are sound and complete, which is a 
desirable feature, although it can make representation in the language more difficult. 

Automatic classifications are performed by description logic-based languages 
(LOOM and OIL). 

The exception handling mechanism is not addressed, in general, by language 
developers (FLogic is the only one handling exceptions). Works have been carried out 
in other languages, such as LOOM, to support them. 



Table 8. Reasoning mechanisms of the language 



REASONING 


Onto 


OKBC 


OCML 


LOOM 


FLogic 


XOL 


SHOE 


RDF(S) 


OI 

L 


INFERENCE ENG. 




















Sound 


- 


- 


+ 


+ 


+ 


- 


- 


- 


+ 


Complete 


- 


- 


- 


- 


+ 


- 


- 


- 


+ 


CLASSIFICATION 




















Automatie classif. 


- 


- 


- 


+ 


- 


- 


- 


- 


+ 


EXCEPTIONS 




















Exeeption handling 


- 


- 


- 


- 


+ 


- 


- 


- 


- 


INHERITANCE 




















Monotonie 


+ 


+ 


+ 


+ 


+ 


ND 


+ 


ND 


+ 


Non-monotonie 


+/- 


+ 


+/- 


+ 


+ 


ND 


- 


ND 


- 


Single Inheritanee 


+ 


+ 


+ 


+ 


+ 


ND 


+ 


+ 


+ 


Multiple inheritance 


+ 


+ 


+ 


+ 


+ 


ND 


+ 


+ 


+ 


PROCEDURES 




















Execution of 
procedures 


+ 


+ 


+ 


+ 


- 


- 




- 




CONSTRAINTS 




















Constraint checking 


+ 


+ 


+ 


+ 


+ 


- 


- 


- 


- 


CHAINING 




















Forward 


- 


- 


+ 


+ 


+ 


- 


ND 


- 


- 


Backward 


- 


- 


+ 


+ 


+ 


- 


ND 


- 


- 



Single and multiple inheritance is also supported by most of the languages (except 
for XOL), but conflicts in multiple inheritance are not resolved. All languages are 
basically monotonic, although they usually include some non-monotonic capabilities. 
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For instance, the only non-monotonic capabilities present in both Ontolingua and 
OCML are related to default values for slots and facets. In XOL and RDF 
specifications there is no explicit definition of the behaviour of inherited values. 

All the languages which allow to define procedures, allow to execute them. 

Constraint checking is performed in all the traditional ontology languages. 
Information about constraint checking in XOL is not available. In OKBC, constraint 
checking is guaranteed to be included in all implementations of it. However, it can be 
parameterised and even switched off. Constraint checking in SHOE is not performed 
because conflicts are thought to be frequent in the Web, and resolving them will be 
problematic. However, type constraint checking is performed when necessary. 

Chaining used in SHOE is not defined in the language: freedom exists so that each 
implementation may choose between any of them. OCML allows to define the 
chaining of rules when defining them, although default chaining used is the backward 
one. LOOM performs both kinds of chaining, and FLogic’s one is in between. 



5 Future Works 

Future works in this area will try to identify factors to choose among a set of 
languages when building a domain ontology for an application. Different needs in KR 
and reasoning exist, and some languages are more suitable than others. We 
recommend: 

• Web based languages for the interchange of ontologies on the web. 

• Traditional languages for the representation - modeling - of ontologies with high 
expressiveness needs. However, if ontologies are considered just as taxonomies, 
the use of web-based languages is not a problem. 

• For performing reasoning inside agents, XML-based languages do not provide 
inference engines. However, some of the traditional ontology languages not only 
provide them but also translators to other computable languages. 

Besides, an analysis of the existing tools for editing, managing, integrating and 
translating ontologies (which would extend the one described in [5]) will be useful for 
determining the most suitable language for our needs, and studies on the treatment of 
namespaces in different languages will be also interesting to analyse the easiness of 
integrating and scaling up ontologies. 

Finally, the analysis on how components are codified in each language will also 
help to face up to the translation problem. 
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Abstract. A common problem of ontologies is that their taxonomic struc- 
ture is often poor and confusing. This is typically exemplified by the unre- 
strained use of subsumption to accomplish a variety of tasks. In this paper we 
show how a formal ontology of unary properties can help using the subsump- 
tion relation in a disciplined way. This formal ontology is based on some 
meta-properties built around the fundamental philosophical notions of iden- 
tity, unity, essence, and dependence. These meta-properties impose some 
constraints on the subsumption relation that clarify many misconceptions 
about taxonomies, facilitating their understanding, comparison and integra- 
tion. 

1 Introduction 

Ontologies are becoming increasingly popular in practice, but a principled methodolo- 
gy for building them is still lacking. Perhaps the most common problem we have seen 
in practice with ontologies is that, while they are expected to bring order and structure 
to information, their taxonomic structure is often poor and confusing. This is typically 
exemplified by the unrestrained use of subsumption to accomplish a variety of reason- 
ing and representation tasks. For example, in previous work [5] several unclear uses of 
the is-a relation in existing ontologies were identified, such as: 

1. a physical object is an amount of matter (Pangloss) 

2. an amount of matter is a physical object (WordNet) 

This striking dissimilarity poses a difficult integration problem, since the standard ap- 
proach of generalizing overlapping concepts would not work, and shows that even the 
most experienced modelers need some guidance for using subsumption consistently. 

Our answer to problems like this lies in a better understanding of the nature of the 
properties corresponding to taxonomic nodes. To facilitate this understanding, we first 
introduce some meta-properties resulting from a revisitation of the fundamental philo- 
sophical notions of identity, unity, essence, and dependence, and we show how they im- 
pose some natural constraints on taxonomic structure that facilitate ontology under- 
standing, comparison and integration. We then explore in a systematic way how these 
meta-properties can be combined to form different kinds of properties. The result of this 
analysis is a meta-level ontology of properties, which helps to make explicit the mean- 
ing every property has within a certain conceptualization. 
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Our formal ontology of properties is part of a methodology for ontology-driven con- 
ceptual analysis which combines the established tradition of formal ontology in Philos- 
ophy with the needs of information systems design [4], An more detailed overview of 
the methodology can be found in [7]. 

2 Background 

This section provides an overview of previous work, intuitive descriptions of the basic 
meta-properties used to form our ontology of properties, and a discussion of related no- 
tions from other information systems fields. 

2.1 Previous Work 

The need of distinguishing among different kinds of property is recognized only spo- 
radically in the vast literature on knowledge representation, knowledge engineering, 
database conceptual modeling, and object oriented modeling. 

We briefly discuss in this section a few papers belonging to the knowledge engi- 
neering and knowledge representation area. A more complete treatment of previous and 
related work can be found in [7]. 

Uschold and Gruninger [17] describe their methodology as a skeleton, acknowl- 
edge places in which “flesh” needs to be added. In our experience, one such place is in 
the area of organizing principles for taxonomies: there are in general a multitude of 
ways to represent the same knowledge, and there exists very little guidance forjudging 
when one approach is better than another. 

Some effort to accomplish this was made several years ago by the IDEF group in 
establishing the IDEF5 ontology capture method [1]. Of particular relevance to this pa- 
per, the IDEF5 method attempts to clarify the difference between kinds, classes, types, 
attributes, and properties. The specified differences, however, become vague and con- 
fused in a number of places. For example, 

“[Kinds] should not be identified with types or classes. [They share 
characteristics that are, however] distinguishing features of what are 
typically called properties. Because properties are already a part of 
[IDEF5], it will ... be convenient to take kinds to be properties of a 
certain distinguished sort.” (p. 16). 

This definition still leaves completely open the question of how to distinguish kinds 
from other properties. The authors are clearly aware of subtle differences here, but did 
not precisely specify what those differences are. We have attempted to do this by first 
identifying the formal tools required to make such distinctions, and placing these dis- 
tinctions within our methodology. 

A first attempt to draw some formal distinctions among properties for knowledge 
engineering purposes was made in [2], and later in [3]. The present work can be seen 
as a radical extension and refinement of the latter paper, with a better account on the 
underlying philosophical notions (especially identity), a complete combinatorial anal- 
ysis of the space of property kinds, and more emphasis on the impact of these distinc- 
tions on a general methodology for ontological analysis. 

One particular kind of property we discuss here, namely roles, is discussed in great 
detail in a recent paper [15]. 
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2.2 The Basic Notions 

At the core of our methodology are three fundamental - and yet intimately related - 
philosophical notions: identity, unity, and essence (a fourth notion, dependence, will be 
discussed later). The notion of identity we adopt here is based on intuitions about how 
we, as cognitive agents, in general interact with (and in particular recognize) individual 
entities in the world around us. It fits therefore the paradigm of descriptive metaphysics 
[16], whose goal is to provide a framework in which the world as perceived by us can 
be analyzed and described. Despite its fundamental importance in Philosophy, it has 
been slow in making its way into the practice of conceptual modeling for information 
systems, where the goals of analyzing and describing the world are ostensibly the same. 

The first step in understanding the intuitions behind identity requires considering 
the distinctions and similarities between identity and unity. These notions are different, 
albeit closely related and often confused under a generic nofion of identify. Strictly 
speaking, identity is related to the problem of distinguishing a specific instance of a cer- 
tain class from other instances of that class by means of a characteristic property, which 
is unique for it (that whole instance). Unity, on the other hand, is related to the problem 
of distinguishing the parts of an instance from the rest of the world by means of a uni- 
fying relation that binds them together (not involving anything else). For example, ask- 
ing “Is that my dog?” would be a problem of identity, whereas asking “is the collar part 
of my dog?” would be a problem of unity. 

Both notions encounter problems when time is involved. The classical one is that 
of identity through change: in order to account for common sense, we need to admit that 
an individual may remain the same while exhibiting different properties at different 
times. But which properties can change, and which must not? And how can we reiden- 
tify an instance of a certain property after some time? The former issue leads to the no- 
tion of an essential property, on which we base the definition of rigidity, discussed be- 
low, while the latter is related to the distinction between synchronic and diachronic 
identity. An extensive analysis of these issues in the context of conceptual modeling has 
been made elsewhere [6], and further development of meta-properties based on unity 
which are used by other parts of our methodology can be found in [8]. 

Finally, it is important to note that our identity judgements ultimately depend on our 
conceptualization of the world [4]. This means that, while we shall use examples to 
clarify the notions central to our analysis, the examples themselves will not be the point 
of this paper. For example, the decision as to whether a cat remains the same cat after 
it loses its tail, or whether a statue is identical with the marble it is made of, are ultimate- 
ly the result of our sensory system, our culture, etc. The aim of the present analysis is 
to clarify the formal tools that can both make such assumptions explicit, and reveal the 
logical consequences of them. When we say, e.g. that “having the same fingerprint” 
may be considered an identity criterion for PERSON, we do not mean to claim this is 
the universal identity criterion for PERSONS, but that if this were to be taken as an iden- 
tity criterion in some conceptualization, what would that mean for the property, for its 
instances, and its relationships to other properties? 
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2.3 Related Notions 

Identity has many analogies in conceptual modeling for databases, knowledge bases, 
object-oriented, and classical information systems, however none of them completely 
captures the notion we present here. We discuss some of these cases below. 

2.3.1 Membership conditions 

In description logics, conceptual models usually focus on the sufficient and necessary 
criteria for class membership, that is, recognizing instances of certain classes. This is 
not identity, however, as it does not describe how instances of the same class are to be 
told apart. This is a common confusion that is important to keep clear: membership con- 
ditions determine when an entity is an instance of a class, i.e. they can be used to answer 
the question, “Is that a dog?” but not, “Is that my dog?” 

2.3.2 Globally Unique IDs 

In object-oriented systems, uniquely identifying an object (as a collection of data) is 
critical, in particular when data is persistent or can be distributed [ 1 8] . In databases, glo- 
bally unique id’s have been introduced into most commercial systems to address this 
issue. These solutions provide a notion of identity for the descriptions, for the units of 
data (objects or records), but not for the entities they describe. It still leaves open the 
possibility that two (or more) descriptions may refer to the same entity, and it is this en- 
tity that our notion of identity is concerned with. In other words, globally unique IDs 
can be used to answer, “Is this the same description of a dog?” but not, “Is this my dog.” 

2.3.3 Primary Keys 

Some object-oriented languages provide a facility for overloading or locally defining 
the equality predicate for a class. In standard database analysis, introducing new tables 
requires finding unique keys either as single fields or combinations of fields in a record. 
These two similar notions very closely approach our notion of identity as they do offer 
evidence towards determining when two descriptions refer to the same entity. There is 
a very subtle difference, however, which we will attempt to briefly describe here and 
which should become more clear with the examples at the end of the paper. 

Understanding this subtle difference first requires understanding the difference 
between what we will call intrinsic and extrinsic properties. An intrinsic property is 
typically something inherent to an individual, not dependent on other individuals, such 
as having a heart or having a fingerprint. Extrinsic properties are not inherent, and they 
have a relational nature, like “being a friend of John”. Among these, there are some 
that are typically assigned by external agents or agencies, such as having a specific 
social security number, having a specific customer i.d., even having a specific name. 

Primary (and candidate) keys and overloaded equality operators are typically based 
on the latter kind of extrinsic properties that are required by a system to be unique. In 
many cases, information systems designers add these extrinsic properties simply as an 
escape from solving (often very difficult) identity problems. Our notion of identity is 
based mainly on intrinsic properties — we are interested in analyzing the inherent 
nature of entities and believe this is important for understanding a domain. 

This is not to say that the former type of analysis never uses intrinsic properties, nor 
that the latter never uses extrinsic ones - it is merely a question of emphasis. Further- 
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more, our analysis is often based on information which may not be represented in the 
implemented system, whereas the primary key notion can never use such information. 
For example, we may claim as part of our analysis that people are uniquely identified 
by their brain, but this information would not appear in the final system we are design- 
ing. 

Our notion of identity and the notion of primary keys are not incompatible, nor are 
they disjoint, and in practice conceptual modelers will often need both. 

3 The Formal Tools of Ontological Analysis 

In this section we shall present a formal analysis of the basic notions discussed above, 
and we shall introduce a set of meta-properties that represent the behaviour of a prop- 
erty with respect to these notions. Our goal is to show how these meta-properties im- 
pose some constraints on the way subsumption is used to model a domain. 

Our analysis relies on certain fairly standard conventions and notations in logic and 
modal logic, which are described in more detail in [8]. It is important to note that our 
use of meta-properties does not require second-order reasoning, and this is also ex- 
plained further in [8]. 

We shall denote primitive meta-properties by bold letters preceded by the sign 
or which will be described for each meta-property. We use the notation (|)''^ 
to indicate that the property (|) has the meta-property M. 

3.1 Rigidity 

A rigid property was defined in [3] as follows: 

Definition 1 A rigid property is a property that is essential to all its instances, i.e. 
Vx (|)(:r) — > □ (t>(x) . 

from this it trivially follows through negation that 

Definition 2 A non-rigid property is a property that is not essential to some of its 
instances, i.e. 3x (t>(v) a (|)(x) . 

For example, we normally think of PERSON as rigid; if v is an instance of PERSON, 
it must be an instance of PERSON in every possible world. The STUDENT property, on 
the other hand, is normally not rigid; we can easily imagine an entity moving in and out 
of the STUDENT property while being the same individual. This notion was later re- 
fined in [4] : 

Definition 3 An anti-rigid property is a property that is not essential to all its instances, 
i.e. Vx hCv) — > — iD div) . 

Definition 4 A semi-rigid property is a property that is non-rigid but not anti-rigid. 

Rigid properties are marked with the meta-property -l-R, anti-rigid with ~R, non-rig- 
id with -R, semi-rigid with “'R. 

The notion of anti-rigidity was added to gain a further restriction. The ~R meta- 
property is subsumed by -R, but is stronger, as the former constrains all instances of a 
property and the latter, as the simple negation of +R, constrains at least one instance. 
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Anti-rigidity attempts to capture the intuition that all instances of certain properties 
must possibly not be instances of that property. Consider the property STUDENT, for 
example: in its normal usage, every instance of student is not necessarily so. 

Rigidity as a meta-property is not “inherited” by sub-properties of properties that 
carry it, e.g. if we have PERSON*'^ and Vx STUDENT(x) PERSON(x) then we know 
that all instances of STUDENT are necessarily instances of PERSON, but not necessar- 
ily (in the modal sense) instances of STUDENT, and we furthermore may assert STU- 
DENT^. In simpler terms, an instance of STUDENT can cease to be a student but may 
not cease to be a person. 

3.2 Identity 

In the philosophical literature, an identity condition (IC) for a arbitrary property (|) is 
usually defined as a suitable relation p satisfying the following formula: 

(t)(x) <^x = y) (1) 

Since identity is an equivalence relation, it follows that p restricted to (|) must also 
be an equivalence relation. For example, the property PERSON can be seen as carrying 
an IC if relations like having-the-same-SSN or having-the-same-fingerprints are as- 
sumed to satisfy (1). 

As discussed in more detail elsewhere [6], the above formulation has some prob- 
lems, in our opinion. The first problem is related to the need of distinguishing between 
supplying an IC and simply carrying an IC: it seems that non-rigid properties like STU- 
DENT can only carry their ICs, inheriting those supplied by their subsuming rigid prop- 
erties like PERSON. The intuition behind this is that, since the same person can be a 
student at different times in different schools, an IC allegedly supplied by STUDENT 
(say, having the same registration number) may be only local, within a certain student- 
hood experience. It would not supply therefore a “global” condition for identity, satis- 
fying (1) only as a sufficient condition, not as a necessary one. 

The second problem regards the nature of the p relation: what makes it an IC, and 
how can we index it with respect to time to account for the difference between synchro- 
nic and diachronic identity? 

Finally, deciding whether a property carries an IC may be difficult, since finding a 
p that is both necessary and sufficient for identity is often hard, especially for natural 
kinds and artifacts. 

For these reasons, we introduce below a notion of identity conditions that have the 
following characteristics: i) they can only be supplied by rigid properties; ii) they re- 
formulate the p relation above in terms of a formula that explicitly takes two different 
times into account, allowing the distinction between synchronic (same time) and dia- 
chronic (different times) identity; iii) they can be only sufficient or only necessary. 

Definition 5 A rigid property (|) carries the necessary IC T{x,y,t,t') if F contains x,y,t,f 
as the only free variables, and: 

—Nxytt’iJ'{x,y,t,t') ^ xx=y) (2) 

E(x,f) A (|)(x,f) A £(7,0 A ISfiy.t’) A x=y ^T{x,y,t,t') (3) 
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— iV;(y(E(x,f) A (|)(x,f) A E(y,f) A (|)(y,f’) — ^ (4) 

Definition 6 A rigid property (|) carries the sufficient 1C T{x,y,t,t') if E contains x,y,t,t' 
as the only free variables, satisfies (2), and: 

E(x,t) A i^(x,t) A E(y,t') A (jiCy,?’) a T(x,y,t,t') x=y (5) 

3xytt' r(x,y,t,t'). (6) 

In the formulas above, E is a predicate for actual e?(istencea.t time t (see [8] for further 
clarification of our usage, which is based on [9]), (2) guarantees that E is bound to iden- 
tity under a certain sortal, and not to arbitrary identity, (4) is needed to guarantee that 
the last conjunct in (3) is relevant and not tautological, and (6) ensures that E is not triv- 
ially false. 

ICs are “inherited” along a hierarchy of properties, in the sense that, if c|)(jc) ^ (p(x) 
and, for example, E is a necessary IC for tp, then (3) above will hold for (|) replacing tp. 

Definition 7 A non-rigid property carries an IC E iff it is subsumed by a rigid property 
carrying E. 

Any property carrying an IC is marked with the meta-property +I (-1 otherwise). 

Definition 8 A property (|) supplies an IC E iff i) it is rigid; ii) it carries E ; and iii) E is 
not carried by all the properties subsuming (|). This means that, if (|) inherits different 
(but compatible) ICs from multiple properties, it still counts as supplying an IC. 

Any property supplying an IC is marked with the meta-property -i-O (-0 otherwise). 
The letter “O” is a mnemonic for “own identity”. 

Erom the above definitions, it is obvious that +0 implies +I and +R. Eor example, 
both PERSON and STUDENT do carry identity (they are therefore +1), but only the 
former supplies it (+0). 

Definition 9 Any property carrying an IC (+1) is called a sortal [16]. 

Notice that to recognize that a property is a sortal we are not forced to know which 
IC it carries: as we shall see, distinguishing between sortals and non-sortals is often 
enough to start bringing order to taxonomies. 

3.3 Dependence 

The final meta-property we employ as a formal ontological tool is based on the notion 
of dependence. This is a very general notion, whose various forms and variations are 
discussed in detail in [14]. We shall introduce here a specific kind of dependence, based 
on Simons’ notional dependence: 

Definition 10 A property (|) is externally dependent on a property \|/ if, for all its 
instances x, necessarily some instance of \|/ must exist, which is not a part nor a constit- 
uent of x: 



VxD (([)(j:) — > 3y \|/(y) a -iF(y, x) a -iC(y, x)) 



(7) 
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The part and constituent relations are discussed further in [8], An externally dependent 
property is marked with the meta-property -l-D (-D otherwise). 

Intuitively, we say that, for example, PARENT is externally dependent on CHILD 
(one can not be a parent without having a child), but PERSON is not externally depend- 
ent on heart nor on body (because any person has a heart as a part and is constituted of 
a body). 

In addition to excluding parts and constituents, a more rigorous definition must ex- 
clude qualities (such as colors), things which necessarily exist (such as the universe), 
and cases where \|/ is subsumed by (|) (since this would make (|) dependent on itself). 

4 Constraints and Assumptions 

Let us now discuss the constraints that follow from our definitions, which are largely 
overlooked in many practical cases [5]. In the following, we take (|) and \\f to be arbitrary 
properties. 

(t)'** can't subsume \|/^** (8) 

This constraint follows immediately from Definitions 1-3. As we shall see, this means 
that if PERSON^^ and AGENT‘S, the latter cannot subsume the former. 

can’t subsume \|T^ (9) 

Properties with incompatible ICs are disjoint. (10) 

(9) follows immediately from our definitions, while (10) deserves some comment. An 

important point is the difference between different and incompatible ICs, related to the 
fact that they can be inherited and specialized along taxonomies. Consider the domain 
of abstract geometrical figures, for example, where the property POLYGON subsumes 
TRIANGLE. A necessary and sufficient IC for polygons is, “Having the same edges and 
the same angles”. On the other hand, an additional necessary and sufficient IC for tri- 
angles is, “Having two edges and their internal angle in common” (note that this condi- 
tion is only-necessary for polygons). So the two properties have different ICs (although 
they have one IC in common), but their extensions are not disjoint. On the other hand, 
consider HMOLWT OF MATTER and PERSON. If we admit mereological extensional- 
ity for the former but not for the latter (since persons can replace their parts), they have 
incompatible ICs, so they must be disjoint (in this case, we can’t say that a person is an 
amount of matter). 

(|)'''° can't subsume \|T° (II) 

This constraint trivially follows from our definitions. 

Finally, we make the following assumptions regarding identity, adapted from [12]: 

• Sortal Individuation. Every domain element must instantiate some property car- 
rying an IC (-I-I). In this way we satisfy Quine’s dictum “No entity without iden- 
tity” [13]. 
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• Sortal Expandability. If two entities (instances of different properties) are the 
same, they must be instances of a single property carrying a condition for their 
identity. In other words, every entity must instantiate at least one rigid property. 

5 Property Kinds 

We now explore the various combinations of meta-properties discussed in the previous 
section in order to charaeterize some basie kinds of properties that usually appear in tax- 
onomies. 

5.1 A systematic analysis 

Analyzing properties based exelusively on the meta-properties discussed in the previ- 
ous section gives us 24 potential categories (I, O, D are boolean, R partitions into three 
cases, +R, ~R, -R). Since -i-O— ^-Fl and -i-O— f-fR we reduce the number to 14, shown 
in Table 1, that eollapse into the 8 relevant classes of properties discussed below. Each 
class is labelled with what we consider as the prototypical kind of property belonging 
to that class. In some cases (for the non-rigid properties), these labels may not be pre- 
cise, in the sense that further investigation is needed to understand the nature of non- 
prototypical properties belonging to a certain class. 



Table 1: Formal ontological property classifications. 
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-FI 


-FR 


+D 


Type 


Sortal 
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+I 
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Formal Role 




-I 


~R 


-D 


Attribution 


-R 


-FD 


-D 






-I 






incoherent 




-FI 


~R 




-R 



The taxonomic structure of these classifications is shown in Figure 1. At the top 
level (the left), we distinguish between sortal and non-sortal properties, based on the 
presence or absence of ICs (the meta-property -Fl). Roles group together anti-rigid, de- 
pendent properties (~R-FD), and split into formal roles (-1) and material roles (-FI). Sor- 
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tals are divided into rigid (+R) and non-rigid (-R), and non-rigid sortals have a further 
speeialization for anti-rigid (~R). This taxonomy refines and extends the work present- 
ed in [2] and [3], 

The next sections describe the meta-properties of each of the classes above, as well 
as the intuitive definition, where properties of that kind should appear in a taxonomy 
(see Figure 2), and examples of the property kind. 

5.1.1 Categories 

Categories are proper- 
ties that are rigid but 
do not carry identity. 

Since they can not be 
subsumed by sortals, 
categories are normal- 
ly the highest level 
properties in an ontolo- 
gy. They carve the do- 
main into useful seg- 
ments, and they are of- 
ten primitive, in the 
sense that no necessary 
and sufficient mem- 
bership conditions can 
be defined for them. 

According to our 
constraints, categories 
can be subsumed by other categories and attributions, and they can subsume any other 
kind of property. In our experience, categories tend naturally to form a tree. We recom- 
mend that at least the topmost categories be disjoint. The archetypal category may be 
ENTITY, other examples may be CONCRETE ENTITY ABSTRACT ENTITY. 

5.1.2 Types 

Types are rigid properties that supply their own identity. They are the most important 
properties in an ontology, being the only ones that supply identity (+ 0 ), and as a con- 
sequence of the Sortal Individuation assumption, every domain element must instantiate 
at least one type. Intuitively, types should be used to represent the main properties in an 
ontology - not the highest level nor the lowest, simply the properties that will be used 
the most when describing the domain. 

Types can only be subsumed by categories, other types, quasi-types, and attribu- 
tions. They can subsume any kind of sortal property, and can not subsume any non-sor- 
tal properties. We recommend that types by subsumed by at least one category. 

Types in general should represent the major properties in an ontology, in our meth- 
odology we recommend starting by enumerating the types in a system, since again they 
should account for every entity. Examples may be PERSON, CAT, and WATER. 
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Top-types are types that are directly subsumed by categories, and are therefore the 
highest level (most general) properties that supply identity. We recommend that top- 
types be subsumed only by categories, and furthermore that all top-types be disjoint to 
the degree possible. Examples may be LIVING-BEING or AMOUNT-OF-MATTER. 

5.1.3 Quasi-Types 

Quasi-types are sortals that do not supply identity, but nevertheless carry it and are rigid. 
They often serve a highly organizational purpose by grouping entities based on useful 
combinations of properties that do no affect identity. Often they tend to introduce new 
necessary and sufficient membership conditions (see the Related Notions section). 

Quasi-types can be subsumed by categories, types, attributions, and mixins, and 
they must be subsumed by at least one type (in order to inherit identity). Quasi-types 
can subsume any sortal property, and can not subsume non-sortal properties. Like types, 
we do not recommend subsuming quasi-types by mixins, and recommend minimizing 
the subsumption of quasi-types by attributions. Examples may be INVERTEBRATE- 
ANIMAL, ox HERBIVORE. 

5.1.4 Backbone Properties 

Collectively, the rigid properties in an ontology (categories, types, and quasi-types) 
form what we call the backbone taxonomy. This is of high organizational importance in 
any ontology, since it identifies the properties that can not change. Backbone properties 
are also considerable value in understanding a ontology, as they form a subset of all the 
properties in the ontology and carry a relevant structural information. The backbone 
carves the domain into useful segmenfs fhrough the categories, identifies every kind of 
entity in the domain through the types, and contains the most useful groupings of enti- 
ties through the quasi-types. 

5.1.5 Formal Roles 

In general, roles are properties expressing the part played by one entity in an event, of- 
ten exemplifying a particular relationship between two or more entities. All roles are 
anti-rigid and dependent (compare this with [2]). In addition, /orma/ roles do not carry 
identity, and intuitively represent the most generic roles that may form the top level of 
role hierarchies. For example, the property of being the PATIENT of an action is a for- 
mal role, since there are no common identity criteria for recipients in general (they may 
be objects, people, etc.). 

Formal roles can be subsumed only by other formal roles, attributions, or catego- 
ries, and can subsume any non-rigid dependent property, therefore dependent attribu- 
tions, dependent mixins, and material roles. We recommend that formal roles be used 
only to organize role taxonomies, i.e. that they not subsume mixins or attributions. Ex- 
amples include PATIENT and INSTRUMENT. 

To capture our intuitions about formal roles (and roles in general) we may need 
more than the simple combinations of meta-properties presented here. There might be 
properties like BEING LOVED BY JOHN\ha.t seem to belong to the same class as for- 
mal roles, without sharing their intuitions. A precise characterization of roles is proba- 
bly still an open issue (see [2], [15]). 
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5.1.6 Material Roles 

Material roles are anti-rigid and dependent, but inherit identity conditions from some 
type. Material roles represent roles that are constrained to particular kinds of entities. 
Intuitively, when a property is recognized to be a role, there should be some event that 
the role corresponds to. 

Material roles can be subsumed by anything, and must be subsumed by at least one 
type (to inherit identity). They can subsume other material roles, and dependent mixins. 
We recommend that material roles only subsume other material roles, and that they be 
subsumed only by roles and backbone properties. 

The prototypical material role is STUDENT, which would be subsumed by PER- 
SON and corresponds to the event enroll, other examples may be MARRIED, and 
FOOD. 



5.1.7 Phased Sortals 

Phased sortals [19] are an interesting kind of property that come from combining a re- 
quirement for carrying identity with anti-rigidity and independence. Although they do 
not supply a global IC, they supply a local IC, corresponding to a certain temporal 
phase of their instances. Intuitively, they account for entities which naturally, yet fun- 
damentally, change some of their identity criteria over time and in discrete phases. For 
example, an individual may at one time be a CATERPILLAR and at another time be a 
BUTTERFLY. Some local ICs change across these phases, but it is still the same entity 
and this fact should be reflected in some global ICs. 

Phased sortals can be subsumed by anything independent, and can subsume any- 
thing non-rigid. According to the Sortal Expandability principle, we have that phased 
sortals must be subsumed by a type, because it must be possible to determine that they 
are the same entity at these two times. We recommend that phased sortals be subsumed 
by backbone properties and that they subsume other phased sortals and material roles. 
Furthermore we strongly recommend that all the phases of a phased sortal be subsumed 
by a type or quasi-type that subsumes only them. 

Phased sortal properties should never appear alone, each phased sortal must have at 
least one other phase into which it changes, but note that this does not make it dependent 
-the properties for each phase will not be instantiated by different entities. 

The prototypical examples of phased sortals are CATERPILLAR and BUTTERFLY. 
True phased sortals seem rare outside of biology, and often properties classified as 
phased sortals are single properties into which multiple meanings have been collapsed 
(see for instance the example of COUNTRY discussed in (7), which might be-mistak- 
enly-classified as ~R thinking that a region may become a country and cease to be a 
country, while a further analysis reveals that geographical regions and countries are dis- 
j oint-although related-entities) . 

Other properties that belong to the same class as phased sortals might be those re- 
sulting from a conjunction of attributions and types, like for instance RED APPLE: de- 
spite RED is usually conceived as semi-rigid (since it may be essential for some instanc- 
es but not for all), it seems plausible to assume that its restriction to APPLE becomes 
anti-rigid (because every red apple might become brown, for instance). In this case, 
RED APPLE is ~R +I -D, being therefore a phased sortal. 
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5.1.8 Attributions 

Attributions are the most relevant example of non-sortal properties that are either semi- 
rigid, or anti-rigid and independent. They intuitively represent values of attributes (or 
qualities) like color, shape, etc. 

The possibility exists that attributions should be always anti-rigid, but we have left 
it open for now, pending further analysis of cases where types have attributions as es- 
sential properties. One might say that e.g. instances of the type HAMMER necessarily 
have the property HARD, whereas other types such as SPONGE have the property con- 
ditionally (a dry sponge is hard, a wet sponge is soft). 

Attributions can subsume anything, and can be subsumed by any non-sortal prop- 
erties. We recommend that attributions subsume only mixins, discussed below, or other 
attributions, and that they be subsumed only by categories. 

Examples include RED, TRIANGULAR, and MALE (assuming that it is possible to 
change sex). 

5.1.9 Mixins 

We generically call mixins all the properties that carry identity and are semi-rigid. These 
properties intuitively represent various combinations (disjunctions or conjunctions) of 
rigid and non-rigid properties. 

Mixins can be subsumed by anything, and can subsume any sortal property. They 
must be subsumed by at least one sortal. We recommend that mixins not subsume rigid 
properties. In a sense, mixins should “hang off’ the backbone. 

Mixins are a difficult kind of property because they are so weakly constrained by 
our meta-properties. For example, the property CAT-OR- WEAPON, subsuming the type 
CAT and the role WEAPON, is semi-rigid; some of its instances (instances of CAT) are 
necessarily so, others (instances of WEAPON and not CAT) are not. We strongly dis- 
courage the use of these artificial properties, and in general recommend minimizing the 
use of mixins. While they may seem useful in large ontologies for organization, we have 
found unrestrained proliferation of this kind of property to generate confusion more 
than order. 

6 Methodology 

Our methodology at the moment focuses mainly on precisely describing properties and 
clarifying their taxonomic structure. One result of this analysis is what we believe to be 
“cleaner” taxonomies. In this section we briefly discuss the part played by the formal 
ontology of properties in the methodology, and then present a short example that uses 
our meta-property analysis to “clean” a taxonomy. 
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6.1 The Role of Property Kinds 

In general, the ideal 
structure of a clean 
taxonomy based on 
our property kinds is 
shown in Figure 2. 

The intuition present- 
ed here is that non- 
rigid properties 
should “hang off’ the 
backbone taxonomy, 
and should not sub- 
sume anything in the 
backbone. This makes 
it possible to easily 
view the rigid proper- 
ties without the non- 
rigid ones, offering a 
simplified view that 
still describes every entity in the domain. This structure is not always possible to 
achieve strictly, but approaching it is desirable. 

In addition to providing this idealized structure, our formal ontology of properties 
also adds to a modeler’s ability to specify the meaning of properties in an ontology, 
since the definition of each property kind includes an intuitive and domain-independent 
description of what part that kind of property should play in an ontology. 

7 Conclusions 

We have presented here the basic steps of a methodology for ontology design founded 
on a formal ontology of properties, which is itself built on a core set of meta properties. 
These meta-properties are formalizations of the basic notions of identity, rigidity, and 
dependence. We have seen how a rigorous analysis based on these notions offers two 
main advantages to the knowledge engineer: 

• It results in a cleaner taxonomy, due to the semantic constraints imposed on the 
is-a relation; 

• The backbone taxonomy is identified. 

• It forces the analyst to make ontological commitments explicit, clarifying the in- 
tended meaning of the concepts used and producing therefore a more reusable on- 
tology. 
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Abstract. Although the necessity of an ontology and ontological engineering is 
well-understood, there has been few success stories about ontology construction 
and its deployment to date. This paper presents an activity of ontology 
construction and its deployment in an interface system for an oil-refinery plant 
operation which has been done under the umbrella of Human-Media Project for 
four years. It also describes the reasons why we need an ontology, what 
ontology we built, what environment we used for building the ontology and 
how the ontology is used in the system. The interface has been developed 
intended to establish a sophisticated technology for advanced interface for plant 
operators and consists of several agents. The system has been implemented and 
preliminary evaluation has been done successfully. 



Introduction 

Ontological engineering [1] is a successor of knowledge engineering which has been 
considered as a technology for building knowledge-intensive systems. Although 
knowledge engineering has contributed to eliciting expertise, organizing it into a 
computational structure, and building knowledge bases, AI researchers have noticed 
the necessity of a more robust and theoretically sound engineering which enables 
knowledge sharing/reuse and formulation of the problem solving process itself. 
Knowledge engineering has thus developed into “ontological engineering” where 
“ontology” is the key concept to investigate. 

Although the necessity of an ontology and ontological engineering is well- 
understood, there has been few suecess stories about ontology construetion and its 
deployment to date. This paper presents an activity of ontology construction and its 
deployment in Oil-refinery plant which has been done under the umbrella of Human- 
Media Project for four years. 

Human Media project, which is a MITI(Japanese Ministry of International Trade 
and Industries) funded national project, is intended to invent an innovative media 
technology for happier human life in the coming information society in 2H‘ century. It 
is something an integration of the three representative media such as Knowledge 
media. Virtual media and Kansei media. “Kansei” is a Japanese term which roughly 
means the sixth or seventh sense sensing for satisfaction, comfort, beauty, softness, 
etc. Our ontology construction activities have been done in the project named 
“Development of a human interface for the next generation plant operation” running 
as a subproject of Human Media project. 
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The interface for oil-refinery plant operation has been developed intended to 
establish a sophisticated technology for advanced interface for plant operators and 
consists of Interface agent: lA, Virtual plant agent: VPA, Semantic information 
presentation agent: SIA, Ontology server: OS and Distributed collaboration 
infrastructure: DCI. The last two are mainly for issues related to system building, 
while the first three are related directly to interface issues. OS has been developed 
employing ontological engineering as a key knowledge media technology [2], 

This paper presents the reasons why we need an ontology, what ontology we built, 
what environment we used for building the ontology and how the ontology is used in 
the system. The next section discusses a short introduction to ontology. Section 3 
explains the role of the plant ontology. Detailed description of the plant ontology we 
built is given in Section 4. Section 5 presents the explanation of its use in the entire 
interface system we are developing. Section 6 describes an ontology development 
environment, Hozo, we developed and used for building the plant ontology. Hozo has 
been extensively used in many other projects in our group and the next version is 
being developed based on our experience and uses’ feedback. Section 7 discusses the 
related work followed by conclusion. 



What Is Ontological Engineering and What Is an Ontology? 

Roughly speaking, ontologies consist of task ontology[3][4] which characterizes the 
computational architecture of a knowledge- based system which performs a task and 
domain ontology which characterizes the domain knowledge where the task is 
performed. By a task, we mean a process like diagnosis, monitoring, scheduling, 
design, and so on. In our context, operation is a task. The idea of task ontology which 
serves as a theory of vocabulary/concepts used as building blocks for knowledge- 
based systems[3][4][5][6] might provide us with an effective methodology and 
vocabulary for both analyzing and synthesizing knowledge-based systems. An 
ontology is understood to serve as a kernel theory and building blocks for content- 
oriented research. 

Why ontology instead of knowledge? Knowledge is domain-dependent, and hence 
knowledge engineering which directly investigates such knowledge has been 
suffering from rather serious difficulties, such as domain-specificity and diversity. 
Further, much of the knowledge dealt with in expert systems has been heuristics 
domain experts have, which makes knowledge manipulation more difficult. However, 
in ontological engineering, we investigate knowledge in terms of its origin and 
elements from which knowledge is constructed. An ontology reflects what exists out 
there in the world of interest or represents what we should think exists there. 
Hierarchical structure of concepts and decomposability of knowledge enable us to 
identify portions of concepts sharable among people. Exploitation of such 
characteristics makes it possible to avoid the difficulties knowledge engineering has 
faced with. The following is an enumeration of the merits we can enjoy from an 
ontology: 

1. A common vocabulary. The description of the target world needs a vocabulary 
agreed among people involved. 

2. Explication of what has been often left implicit. In all of the human activities, we 
find presuppositions/assumptions which usually are left implicit. Any knowledge 
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base built is based on a conceptualization possessed by the builder and is usually 
implicit. An ontology is an explication of the very implicit knowledge. Such an 
explicit representation of assumptions and conceptualization is more than a simple 
explication. 

3. Systematization of knowledge. Knowledge systematization requires well- 
established vocabulary/concepts in terms people use to describe phenomena, 
theories and target things under consideration. An ontology thus contributes to 
providing a backbone for the systematization of knowledge. 

4. Standardization. The common vocabulary and knowledge systematization bring us 
more or less standardized terms/concepts. 

5. Meta-model functionality. A model is usually built in the computer as an 
abstraction of the real target. And, an ontology provides us with concepts and 
relations among them which are used as building blocks of the model. Thus, an 
ontology specifies the models to build by giving guidelines and constraints which 
should be satisfied. This function is viewed as that at the metalevel. 



The Role of a Plant Ontology 

Any intelligent system needs a considerable amount of domain knowledge to be 
useful in a domain. The amount of knowledge necessary often goes large, which 
sometimes causes difficulties in the initial construction and maintenance phases. As 
described above, one of the methods we adopted to cope with such problems is 
ontological engineering. The plant ontology makes contributions in our system in 
many respects described above. Roughly speaking, the essential contribution of an 
ontology is making shared commitment to the target plant explicit, and hence 
terminology is standardized within the community of agents. By agents, we also mean 
human agents, operators, to share such a fundamental understanding about the plant. 
This enables the system to communicate with operators using the terms stored in 
Ontology server: OS. It is the second major role of OS in the current implementation 
of the interface system which is discussed below in Section 4. 

In message generation, we need to pay maximal attention to word selection to 
make operators’ cognitive load minimum in message understanding. After an 
intensive interview with domain experts, we found human operators use different 
terms to denote the same thing depending on context. When we first noticed this fact, 
domain experts apologized for this seemingly random fluctuation of word usage, 
since they did not know the reason why they use terms that way and they were used to 
collaboration with computer engineers who do not like neat adaptation and tend to 
compel their idea of “this is what a computer can do, so accept it”. They kindly 
declared that they would soon determine a unique label for each thing. But, we were 
different from such computer engineers. Instead of accepting their proposal, we 
carefully analyzed the way of their word usage and finally came up with that it is not 
random except a few cases. Many of the wording have good justifications which have 
to be taken care of in the message generation. The way of doing so is described in 5.2. 

The reasons why we employed distributed collaboration architecture with multiple 
agents include making the whole system robust and easy to maintain. As is well 
known, however, these merits are not free. We need a well-designed vocabulary for 




116 



R. Mizoguchi et al. 



describing message content as well as a powerful negotiation protocol. Although the 
latter is of importance, it is out of the scope of this paper. 

DCI is responsible for enabling collaborative problem solving by multiple agents 
with the help of OS. It is one of the key factors that domain-dependent knowledge be 
isolated in OS so that DCI can be as general as possible. 



Plant Ontology 

We built a plant ontology which consists of several hierarchical organizations of 
concepts such as operation task ontology, plant components, plant objects, basic 
attributes and ordinary attribute. The key issue in design of an ontology is clear 
distinction essential categories from peripheral or view-dependent concepts. 



Operation Task Ontology 

The major constituents of a task ontology are concepts of action done by the task 
performer, operators in our case, and concepts of the role which domain objects play 
in the task performance. This is the key issue of task ontology. That is, a task 
ontology reveals the problem solving context in a task of interest to specify the roles 
the domain objects play. Without this, it is left implicit that how domain concepts 
should be organized under a specific task. 

Activity Concepts: Operation of a plant consists of monitoring the behavior of the 
plant, diagnosing abnormal states if any and operating devices to recover from such 
states. Thus, the three actions, monitor, diagnose and operate are the top level 
category of action part. Under these, we also identified enumerate, list up, decide, 
predict, etc. 

There are two kinds of hierarchies of concepts organization, is-a hierarchy and 
part-of hierarchy. For example, sub-concepts of operate in the part-of hierarchy 
would be recognize(the state), predict{the near future), identify(t\\Q causes), and 
decide (operation to take). On the other hand, sub-concepts of reason in the is-a 
hierarchy, are predict and retrospectively reason and its super is think. In the is-a 
hierarchy case, properties of the super concepts are inherited to the sub-concepts. In 
reason case, its [input : output] roles, [state : state], are inherited by predict and 
retrospectively reason but specialized to [current state : future state] and [current state 
: causal state]. 



Role Concepts: Major task-specific role concepts include state of operation, 
abnormal state, candidate cause, countermeasure operation etc. When a state of 
operation is recognized as abnormal, then it comes to be called abnormal state. Near 
future state is a state predicted from an abnormal state as the current state. A cause 
of a fault has its sub-states: a candidate cause which is an inferred causal state and a 
cause which is a real cause. 
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Fig. 1. A Portion of Plant Object is-a Hierarchy in the Plant Domain Ontology 



Domain Ontology 

There exist two major things in the plant domain: Plant components(devices) and 
plant objects to be processed by the devices. Domain concepts also have role concepts 
like task ontology. To say precisely, many of the domain concepts are role concepts. 
The first things we have to do when designing a domain ontology is discrimination of 
roles concepts from essential categories( or basic concepts), i.e., view- or context- 
independent concepts. Let us first take plant object. The top-level categories of plant 
object are view-independent object and view-dependent object. The former includes 
LP gas, gasoline, naphtha, etc. which are categories persistent in any situation. The 
latter includes tower-head ingredient, liquid, distillate, input, intermediate product, 
raw material, fuel, etc. All are view- or context-dependent. The major task needed 
was categorization of such dependency. Fig. 1 shows a portion of plant object is-a 
hierarchy. The top-level categories of view-dependent plant object are state- 
dependent, location-dependent, history-dependent and role-dependent objects, state- 
dependent objects has inherent state-dependent and relative state-dependent objects 
as its sub-concepts. The former includes liquid, gas, superheating steam etc. and the 
latter low temperature ingredient, low boiling point ingredient, etc. 
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Fig. 2. Block diagram of Ontology server 



Attribute also needs careful treatment. Most of the attributes people think so are 
not true attribute but role attribute. Let us take an example of height. It is a role 
attribute whose basic attribute is length. Height, depth, width and distance are role 
attributes. Just like a man is called a husband when he has got married. The true 
attribute is ealled basic attribute. Examples of basic attribute include length, area, 
mass, temperature, pressure, volt, etc. Role attribute includes height, depth, input 
pressure, maximum weight, area of cross section, etc. Needless to say, these 
attributes are also decomposed into several sub-eoncepts. 

We finally built an ontology which contains about 500 concepts whieh are 
approved by the domain experts and the coverage is around the normal pressure 
fractionator of a full-scale refinery plant. 

Another kind of domain ontology is neeessary to build a model of a plant as an 
active artifact. That is an ontology of function and behavior which is task- 
independent. This ontology is used for deeper understanding of the dynamie 
characteristics of an artifact. Although it is interesting, it is omitted in this paper 
because of the spaee limitation [8] [9]. 
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Use of the Ontology 

System Overview of Ontology Server: OS 

Ontology server has several functions in the interface system. 

(1) To store the plant ontology for use of representing message contents. 

(2) To build a model of the target plant shared by other agents 

(3) To generate natural language messages presented to operators according to 
appropriate word selection 

(4) To answer questions about the structure of the plant 

(5) To translate among vocabularies local to each of the agents. 

In general, the major contribution of OS to the whole system is to standardize 
concepts about the target plant each agent has as well as vocabulary used by them. 
Fig. 2 shows the block diagram of OS where several types of plant ontologies are 
stored and two functional modules such as explanation generator and message 
generator are also shown. OS has a stylized application protocol interface supported 
by DCI, by which any agent can communicate with OS and can inspect the ontology 
in it. 



Appropriate Word Selection 



After intensive discussion with domain 
experts, we found a remarkable fact that 
they sometimes use multiple names to 
denote the same entity. Let us take an 
example shown in Fig. 3 in which two 
controllers exist: Level controller 

(LC29) and flow controller (FC29). 

Both controllers use the same control 
valve as an actuator. It is a typical 
example of cascaded control. LC29 
takes care of the liquid level of the 
overhead drum which contains 
reflux(Naphtha). And FC29 is in charge of controlling the flow of Naphtha coming 
out of the overhead drum. The control valve is called “Level adjustment control 
valve” and “Naphtha extraction flow control valve” depending on which controller 
the operator focuses on. The problem, however, is that the focused controller is 
seldom explicit. So, the system has to infer where is the focus on and to trace the 
focus shifts during the course of operation. Further, the system has to know the term 
generation mechanism to attain the maximal flexibility of the system. Concerning the 
labels of each concept, we only ask the model builder of the target plant to write the 
default name of things appearing in the plant. The role name which will be attached to 
things are basically generated by the system according to the context identified. This 
makes system building easier. Especially, plant objects have various role names 
which the objects play from the viewpoint of the device which processes them. For 




Fig. 3. Cascaded control of 
LC and FC 
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example, input material is a typical role name which many of the plant objects could 
play. 

The system has two kinds of rules such as Focus tracing rules and Role name 
generation rules. The former is for tracing the focal point to identify the context and 
the latter for “name” generation of the target entity. The philosophy of name 
generation is to associate a default name with each entity and rules are invoked when 
names other than the default one should be used. Note that roles names are generated 
adaptively to the topological structure of the plant. 

While the rule application, knowledge about each concept/term is obtained by 
consulting the ontology and the plant model which has been built by connecting 
components generated by instantiation of corresponding concepts in the ontology. 



Focus Tracing Rules 

Assume the system is asked to choose an appropriate term for things(attributes, name, 

etc.) of an object identified by its unique identifier. Let us call the object CO: Current 

Object. The rule are divided into four cases according to what things of CO is: 

Case 1: An attribute of a plant object(not a device) 

(a) If CO is input or output of the device focused previously, then the focused device 
is the same as the last focused device. 

(b) If the last focused device is either a controller or a control valve and CO is equal 
to that the controller measures, then the device the controller measures is the new 
focused device. 

(c) If the task is decision of countermeasure, then the new focused device is the entire 
plant. 

(d) Otherwise, no focused device exists. 

Case 2: An attribute of a device 

(a) If a controller which measures the attributes exists, then the new focused device is 
the controller. 

(b) Otherwise, the new focused device is the same as the last focused device. 

Case 3: A control valve(CO is a control valve itself) 

(a) If CO is the same as the target object of the last focused device, the focused device 
is the same as the last focused device. 

(b) Otherwise, the device which operates CO is the new focused device. 

Case 4: others 

(a) In all cases where device names are concerned other than the cases (2) and (3), CO 

is the new focused device. 



Role Name Generation Rules 

The philosophy is to associate a default name with each thing and rules are invoked 
when names other than the default one should be used. 

(1) For plant objects 

(a) If there is a focused device, then 
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(a-1) if the focused device has role names of its input/output objects, then CO 
name is the role name of the input/output object of the focused device. 
(a-2) otherwise, the CO name is “<focused device> input/output”. 

(b) Otherwise, default name of CO is used. 

(2) For a controller and a control valve 

(a) If the focused device measures an attribute of another device, then the name of 
the CO is “<the device which focused device controls>” + ”<the attribute>” + 
[“control valve” or “controller”](e.g., overhead drum level controller). 

(b) If the focused device measures an attribute of a plant object and if the device 
controlled by the focused device has a role name of its input/output object, 
then CO name is “<the role name>” + “<the attribute>” + [“control valve” or 
“controller”]. If there is no role name, then the CO name is “<the controlled 
device>” + [“inlet” or “outlef’j + “<the attribute>” + [“control valve” or 
“controller”](e.g., desalter inlet temperature controller). 

(3) For a thing other than a control valve or a controller 

(a) If an attribute of CO is concerned, then return “<the object which the focused 
device measures>” + “<the attribute>”. 

(b) Otherwise, CO name is the name of the focused device. 



Template Design of Messages 

A message should be easily understood by operators in any situation. So, its syntactic 
form should be highly stylized and cannot be long. We collected a lot of sample 
messages with the help of domain experts and classified the syntactic forms into the 
following seven types: 

(1) Warning 

(2) Near future prediction 

(3) Candidate cause presentation 

(4) Diagnosis result presentation 

(5) Justification of decisions 

(6) Countermeasure presentation 

(7) Justification of countermeasures 

Each type has a few templates for covering a small amount of variations. Each 
template is specified using concepts in the ontology. Message construction algorithm 
can be simple for the above reason. In fact, a simple blank filling method is 
employed. Templates are described in terms of intermediate categories contained in 
the ontology. 

Example: OS receives a message content from Interface Agent which monitors the 
plant. A message content is represented in a list as follows: (<Template type> <non- 
terminal symbols>*) 
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J: [1^ [VFC29,MV1 ±M] 

E: [Warning [VFC29, MV] full throttle] 

J : S ^ 7 -9- tS ^ L M =1 > F p - J u / < 7 u ^ ± -e t 

E: Warning: Naphtha extraction flow control valve is in full 
throttle. 

J:[)^EHSffii [VFC29] 

E: [Candidate causel [VFC29] stick] 

E: Plausible cause: Rellux drum level control valve sticks. 



Implementation and Evaluation 

OS has been implemented in Java and Lisp. The ontology developed has been 
implemented in Ontology editor discussed in Section 6. The number of concepts in 
the ontology is about 500. We did a full-scale experiment to evaluate the system. 
Domain experts developed seven scenarios of various faults with countermeasures for 
them and many types of messages to operators. The templates we built cover all the 
messages. We picked up all of the messages to evaluate the word selection and 
message generation functions of OS and confirmed all of the message contents sent 
from lA through LAN were successfully translated into the desirable messages in 
terms of appropriate terms. Fig. 4 shows an example screen dump of the prototype 
system . The lower half is a portion of the plant model we built and the left upper 
window is a window of lA and right one is of OS. The window configuration is 
arranged for demonstration. The plant model generated using the ontology is shared 
by all the agents. The domain experts evaluated the performance of the system 
favorably. 



An Environment for Ontology Development and Its Use 

The environment, named “Hozo”, used for building the plant ontology and model, is 
composed of graphical interface, editor and ontology/model server in a Client-Server 
architecture. It is implemented in Java and editor is implemented as Java applet so 
that it can work as a client through the Internet. Hozo manages ontologies and models 
for each of the developers. Users can read and copy all the ontologies and models 
stored in Hozo, but cannot modify any developed by others. Models are built by 
choosing and instantiating concepts in an ontology and by connecting the instances. 
After consistency checking of the model using axioms defined in the ontology, the 
model is ready for use by other agents. The model built is available in a Lisp format 
which is sound and machine interpretable. 
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Editor 

The editor interface is composed of the following five parts: 

1 . Browsing panel displays an ontology/model graphically 

2. Definition panel where definition of concepts and relations is done. 

3. Term list panel lists all the concepts contained in the ontology alphabetically and 
is used for concept retrieval. 

4. Menu bar for selecting tools 

5. Tool bar for selecting commands 

The editor can be viewed as a kind of two-dimensional language in the sense that 
users can develop an ontology by defining concepts with appropriate relations such as 
is-a, part-of etc. in the browsing panel. User can define their own relations. 
Consistency of the ontology and of the model built from the ontology is 
automatically guaranteed in terms of the subsumption and instance-of relations. 
Attributes are defined in the definition panel for each concept with the visible 
inheritance history. 



Browsing panel 

Browsing panel has two modes: Tree mode and Network mode. The former 
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displays the ontology in a hierarchical structure using only is-a relations between 
concepts. In the latter mode, all the relations including those user defined are shown 
in a network structure. In the both modes, slots of a concept, usually representing its 
attributes and parts, can be shown by request. A number of mouse operations for 
manipulating trees and networks are available. 

Definition panel 

Definition panel allows users to read and define concepts and relations they 
designate in the Browsing panel. Items for edition are as follows: 

label: It denotes a label denoting the concept being defined, 
axiom: Constraints which has to be satisfied by all of its instances, 
def: Informal definition in natural language 
slot:(kind, name(label), class constraint, value) 

“kind” denotes kinds of content of the slot such as attribute and part etc. “name” 
is a label of the slot, “class constraint” denotes what class should the “value” belong 
to and “value” is a value in the case that “kind” is attribute or a part in the case that 
“kind” is part. These are used for consistency checking by the server, and hence, 
property inheritance and consistency between subsumption and instance-of relations 
are checked by the server. 

Model construction 

A model is built using the ontology developed and is used by other agents. As 
described in the above, Hozo guarantees the compliance of the model with the 
ontology. All the necessary operations such as instance making, connecting them, 
deletion/ addition of instances, etc. for building and manipulating a model are done by 
built-in mouse operations in the browsing panel. During the model construction, users 
are given all the classes defined in the ontology to instantiate. So, the browser works 
as a model browser/editor. When the user selects a class to instantiate, its definition is 
displayed in the class-browsing panel. All the instances built properly inherit 
properties of all of their super-concepts. In fact, the model used in OS has been built 
like this and shared by all of the other agents as an ontology-compliant model. 

Other functions 

Managing and overriding inheritance 

Managing is-a inheritance is done by Hozo automatically. When necessary, 
overriding the inherited value is allowed to specialize it more. 
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GIF attachment 

A node, which denotes concept(class and instance), is usually displayed as a 
square. If necessary, GIF can be attached to it to make the instances real just like 
we did in our project which is shown in Fig. 4. 



Output in a text format 

The ontology and model can be output not only in a Lisp format for computer 
interpretation but also in a text format with indentation. XML version will be ready 
soon. 



Implementation 

The current version of Hozo has been implemented in Java(JDKl.l) and been used 
for two years not only by our lab members but also by some researchers outside. The 
following are some example ontologies developed thus far: 

1 . Ontology for Learning support systems 

2. Ontology for Authoring systems 

3. Ontology for Instmctional design 

4. Ontology of fault in diagnostic tasks 

5. Ontology of function in artifact design 

Fig. 5 shows a snapshot of the plant ontology definition about Component in a 
Network view mode. A node has its super concept to its left and has several slots for 
attribute and its part definition. Components are classified according to their functions 
because function is an essential property of them. Controller inherits “control 
function” from its super concept “Component for control” and has specialized 
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information such as its “control object is an instance of actuator” is written in the slot. 
While a slot is defined as “PV(Process Variable) takes a “value” in “Controller”, that 
of its sub-concept, “Flow controller”, is defined as “PV takes a “value of amount of 
flow” by overriding it. 

Hozo is available at the URL: http://www.ei.sanken.osaka-u.ac.jp/oe/oe.html 



Future Work 

We have identified some room to improve Hozo through its extensive use. The first 
topic is about effective guidelines for ontology development that is badly needed by 
developers. Because many of the existing guidelines are those similar to Software 
development guidelines, we need neater one, that is, one which can help users 
distinguish between classes and roles, identify appropriate relations and build a proper 
abstraction hierarchy of classes. Although this topic is the most important, it is out of 
the scope of this paper. 

Other topics include basic functions which support neat representation of an 
ontology. Especially, we extended Hozo with respect to treatment of “Relation” and 
“Role” concepts. The following is the summary of extension: 

• On the basis of that most of the things are composed of parts and that those parts 
are connected by a specific relation to form the whole, we introduced “Wholeness 
concepf’ and “Relation concept”. The former is a conceptualization of the whole 
and the latter of the relation. Typical example is “married couple(fufu in 
Japanese)” and “fufu relation”. Hozo will provide functions to manage the 
correspondence between these two different conceptualizations of the same entity. 
Needless to say, Hozo gives an identity to every relation. 

• Description framework of roles: Role is specified in various ways. One of the 
typical way is specification in a part-of relation, like “husband” in “fufu”, that is, 
husband is a role in a wholeness concept of a married couple(fufli). 

• Sophisticated display of part-of relations and its editing 

The current Hozo has only one part-of relation which is transitive, but the next 
version will introduce several part-of relations some of which are not transitive. 

• Augmentation of the axiom definition and the language 

The latest version of Hozo has been currently implemented and will be open soon. 
Compatibility to existing ontology representation method like OIL[10] will be 
considered. 



Related Work 

0NT0GENERATI0N[1 1] explains the content of ontology in Spanish based on two 
kinds of ontologies: domain and linguistic ontologies. Message generation in our 
system is not special. Templates are designed by observing sample messages provided 
by the domain experts. Sentence structure of the message is highly stylized because of 
the small number of templates. Its unique feature exists in context-sensitive word 
selection rather than sentence generation itself 
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Our view of an ontology is based mainly on its use in building a well-founded 
model, that is, we think meta-model functionality is of the most important. This 
contrasts well with that of Guarino’s idea of top-level ontology design[7]. The idea of 
task ontology shares a lot with Common KADS[4][5]. 

Several ontology development methodologies have been proposed[12][14]. Both of 
them present users guidelines to follow together with sophisticated tools like those 
employed in the conventional knowledge acquisition process. Most of the tools are 
based on a frame-based knowledge representation language with an additional 
functionality for writing axioms. Hozo is similar to them in that sense, but is different 
from them in some respects: (1) It is essentially a GUI-based language. An ontology 
is defined through the graphical interface based on is-a and /»art-o/hierarchies. (2) It 
has special functionalities for ontology design such as treatment of role concepts 
whose instatiation is done differently from that of a basic concept. (3) Clear 
discrimination among, role(husband role), role-holder(husband) and basic 
concept(man) is done to treat “Role” properly. (4) In the next version of Hozo, 
several kinds of part-of relations are to be introduced such as component-part-of 
which is the most common part-of relation, material-part-of and so on[13]. (5) It 
does not allow multiple inheritance because most of the use of multiple inheritance in 
knowledge representation are inappropriate from ontology point of view. 

Hozo shares an idea of ODE of METHONTOLOGY[14] in that it generates 
machine code of the ontology defined in a more informal way. 



Conclusion 

Plant ontology and its roles in the interface system for oil-refinery plant operation 
have been discussed. The plant ontology design has been almost completed and its 
utility has been demonstrated in message generation with appropriate word selection. 
The future work until the end of the project, March in 2001 includes design of a 
negotiation ontology for use of flexible and powerful collaboration among agents 
through sophisticated negotiation. Task ontology will be used for specifying 
functionality of each agent and hence for helping negotiation task ontology design. 
This topic is one of the main topics in our research plan. 

We also discussed an environment for ontology development, Hozo, used for the 
development of our plant ontology. It was informally evaluated by domain experts 
and they gave favorable comments. They found utility of Hozo in making their 
knowledge explicit and in operationalizing it and want to use it in the daily activity. 
Hozo has been extensively used in many projects to develop various ontologies. Its 
revised version will be ready soon. 
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Abstract. Guidelines for clinical practice are being introduced in an extensive 
way in more and more different fields of medicine They have the potential to 
improve the quality and cost-efficiency of care in a complex health care 
delivery environment. Computerization may increase the effectiveness of both 
the information retrieval of guidelines and the management of guideline-based 
care. The scenario is evolving from stand-alone workstations to telematics 
applications that enable guidelines development and dissemination. However, 
such a knowledge sharing requires the definition of formal models for 
guidelines representation. The models should have a clear semantics in order to 
avoid ambiguities. The role of ontologies is that of making explicit the 
conceptualizations behind a model. In this paper we present our library of 
generic and domain ontologies and point out its role for integrating existing 
guideline models and defining standard representations. In particular, we stress 
the distinction -often collapsed within existing guideline models- between the 
conceptualization of actual procedures, the conceptualization of planning, and 
the conceptualization behind the diagrammatic representation of plans. 



1 Introduction 

Guidelines for clinical practice are being introduced in an extensive way in more and 
more different fields of medicine [1][2]. They have the goal of indicating the most 
appropriate decisional and procedural behavior optimizing health outcomes, costs and 
clinical decisions. 

Guidelines can be expressed in a textual way as recommendations or in a more 
formal and rigid way as protocols or flow diagrams. In different contexts they can be 
either a loose indication for a preferred set of choices or they can be considered a 
normative set of rules. 

Clinical practice guidelines are seen as a tool for improving the quality and cost- 
efficiency of care in an increasingly complex health care delivery environment. It has 
been proved that adherence to plans may reduce cost of care up to 25% [3]. 

However the overwhelming number of guidelines available makes it difficult to 
select the right one. Just to give an idea of the figures, it is reported that there are 855 
different guidelines for British GPs ranging from a single page to small booklets of 
more than 15 pages [4]. 
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Computerization may increase the effectiveness of both the information retrieval of 
guidelines and the delivery of guideline-based care. In an optimal scenario they are 
integrated with the information systems operational at the point of care. The full 
potentialities of computerized systems can be exploited in such an environment where 
different processes are executed in parallel on several patients. In this context such 
systems must be able to retrieve the updated situation of every patient, as well as to 
give an overall report on the ward, freeing the physicians to concentrate more on 
clinical decisions. Keeping track of the parallel activities performed, they should 
avoid unnecessary duplication of tasks and prevent possible omissions. 

Several research projects deal with the computer representation and 
implementation of guidelines. In the next paragraph we review some of the most 
relevant ones. The scenario is evolving from stand-alone workstations to telematics 
applications that - utilizing e.g. the Internet - not only support the use of guidelines, 
but also enable their development and dissemination. 

Such a knowledge sharing requires the definition of formal models for guidelines 
representation. The models should have a clear semantics in order to avoid 
ambiguities. The role of ontologies is that of making explicit the conceptualizations 
behind a model. In particular an ontology contains the formal description of the 
entities to which a model makes a commitment and of the relations holding among the 
entities. 

In this paper we present our library of ontologies and point out its role for 
integrating existing guideline models and defining standard representations. 



2 Applications of Clinical Guidelines 

Many efforts have been devoted in the last few years in realizing computerized tools 
for guidelines management (see for example: Vissers and co-workers [5] and Ertle 
and co-workers [6]). 

The European PRESTIGE project (Guidelines for healthcare: faster 

implementation of health care standards) is mainly dedicated to supplying information 
and modelling technology to guidelines in the context of the IV Framework 
Programme (1994-1999) [7]. PRESTIGE aims to produce telematic applications for a 
faster implementation of new standards of quality in clinical practice in Europe. It is 
therefore directed more towards the clinical part, neglecting the organisational and 
administrative components. 

The PRQ/brwia knowledge representation language and associated software tools 
are designed to support the dissemination of medical knowledge by means of 
electronic publishing [8]. It is also a method for specifying clinical guidelines and 
protocols in a form which can be executed by a computer in order to support the 
management of medical procedures and clinical decision making. 

Web based tools for supporting clinical care are becoming increasingly popular 
(see for example [9-11]). The system SMART allows users to access its database - 
storing information on patients following a guideline-based care - by means of the 
Internet [12]. 
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COLLATE is a WWW-enabled workgroup environment designed to support 
dispersed collaborative groups throughout the complete guideline development cycle 
[13]. COLLATE supports document management, collaborative authoring and editing 
over the Internet, and provides methods for accessing and browsing multimedia 
databases of systematic literature reviews and guideline documents, and can provide 
links to external applications such as on-line bibliographic database packages. 

Recently, increasing attention has been paid to formal model of guidelines and 
protocols. For instance, EON is a computational model of treatment protocols [14]. 
The EON framework consists of three different components: the domain knowledge 
base of medical concepts that will specify the application and temporal-abstraction 
knowledge necessary for reasoning, one or more applications that use problem- 
solving methods formulated as collections of CORE A objects and the Tzolkin 
subsystem that performs temporal abstraction and temporal pattern matching. 

This model was the basis for implementing the protocol-based decision-support 
module for the already existing T-Helper system [15]. This system was originally 
aimed at supporting AIDS care, but, because its architecture was domain independent, 
it was possible to substitute the AIDS knowledge base with another one regarding 
breast cancer. The Protege-II tool was employed to create an ontology of concepts 
related to the management of breast cancer [16]. Such a reuse of knowledge allowed 
the Stanford researchers to implement their prototype system in less than one week. 

The successful experience of the EON model demonstrates that knowledge-based 
systems cannot be constructed in isolation from development in the software- 
engineering community. Their approach, oriented to modularity and to the definition 
of ontologies, facilitated knowledge re-use. 



3 An Excerpt of Our Ontology Library 

Ontologies not only make knowledge re-use easier, they are also the foundation of 
standardization efforts since they make explicit the conceptualizations behind a 
terminology or a model. The actual demand is not for a unique conceptualization, but 
for an unambiguous communication of complex and detailed concepts (possibly 
expressed in different languages), leaving each user free to make explicit his/her 
conceptualization. 

We developed ONIONS, a methodology for integrating domain terminologies by 
exploiting a library of generic theories [17]. By means of this methodology we 
realized the library of ontologies ON9.2 (available in Ontolingua at: 
http://saussure.irmkant.rm.cnr.it), including both general and domain specific 
ontologies [18]. The ontologies related to guidelines, which we will sketch out in the 
next paragraph, are part of this library. Figure 1 reports a fragment of the library 
architecture. Each oval represents an ontology, i.e. a module which embodies the 
formal definition of related concepts and relationships. 

Arrows denote inclusion between ontologies: the specific one includes the generic 
one (e.g. "medical procedures" includes "procedures"). 
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"Clinical activities" is one ontology included by "guidelines", meaning that its 
concepts and relationships are used by the former one. It consists of the main types of 
entities involved in clinical activities, including: "patient", "patient group", "health 
care operator", "medical device", "health care structure", "medical sign" and "health 
condition", and some actor-like relations that divide into: 1) treatment relations, i.e. 
"treats" (between a "health care operator" and a "health condition"), and other 
composed relations (i.e. chaining "treats" with other relations) that account for 
different senses of "treats", e.g. "treatment-device" (between a "medical device" and a 
"health condition"); 2) diagnosis relations, i.e. "diagnoses" (between a "health care 
operator" and a "health condition"), and some composed relations; 3) care relations, 
i.e. "cares for" (holding between a "health care operator" and a "patient" or "patient 
group"), and some composed relations. 

C^lannin'i^^ (^rocedur"^ 




Fig. 1. An excerpt from the ontology library ON 9.2, showing the included theories nearest to 
the guidelines theory. 



"Medical procedures" contains the definition of the main types of medical 
procedures, deriving from the integration of the UMLS Semantic Network [19] and 
the types defined by the Institute of Medicine. A medical procedure is a procedure 
having health-care activities as temporal parts. Five main kinds of medical 
procedures are defined: 1) screening and prevention procedures; 2) surgical 
procedures; 3) care of clinical conditions procedures; 4) diagnostic procedures; 5) 
laboratory procedures. 

Procedures 1) to 3) share the need for some "bearer" patient or patient group, some 
pharmacologic resource, and some medical device; 4) are characterized by a patient 
or patient-group "target" and by their "diagnostic action" carried out on clinical 
conditions; 5) are characterized by the fact that they "analyze" some chemical or 
body substance, possibly assessing their effect. Relations such as: "bearer", "target", 
"analyzes", and "diagnostic action" are defined according to the generic ontology 
"actors", which describes the relations holding between the entities participating in 
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processes and situations with a particular role (e.g. "performer", "embodier", 
"instrument", "goal", etc.). 

To implement our ontology we adopted both Ontolingua [20], which is a very 
expressive language, and the Loom knowledge representation system [21] which 
supports automatic classification and semantic consistency check. Both languages 
allow HTML translation and browsing facilities. In particular the Ontosaurus [22], an 
interface to Loom through the CL-HTTP server, is appropriate for allowing 
collaborative development of ontologies [23]. 

What is peculiar to our library is its integration of medical domain and generic 
(domain-independent) ontologies. Examples of generic ontologies include: 
"mereology" or theory of parts, "topology" or theory of wholes and connexity, 
"morphology", or theory of form and congruence, "localization", "time", "actors", 
"planning", etc. 

The relevance of generic theories to the development of ontologies is not always 
recognized. There are a number of significant experiences showing that an ontological 
analysis can profit from theories which are philosophically and linguistically 
grounded [24]. Our position is that generic theories are essential to the development 
of ontologies and to a rigorous conceptual integration of heterogeneous models [25]. 

For example, available formal models of guidelines make commitments to various 
entities and relations associated with guideline specification: plans, diagrammatic 
charting, information requests, actions, decisions, situations, tasks, etc. 

These formal models do not sort out the entities by means of their ontological 
nature, but only on the basis of system design and efficiency issues. 

For example, the Asbru model defines some guideline properties, but it splits them 
in two sets: one (plan status) includes "rejected", "ready", etc., another (plan state) 
includes "aborted", "completed", etc. [26] . 

Understanding such properties within an ontological framework requires at least 
understanding the difference between a plan and a procedure: a plan is an abstract 
entity (a "script") which acts as the method of a procedure, which is a process actually 
occurring in the real world. 

Such distinction can be drawn with the use of some generic theories that define a 
"plan" as a special kind of "abstract entity", a "procedure" as a special kind of 
"process", a "method" relation as a special kind of "actor" relation, and so on. 

Once plan and procedure are kept disjoint in our ontology, one can easily infer why 
the two sets of Asbru properties actually draw that distinction: only a plan can be 
"rejected", and only a procedure can be "aborted". 

If one disagrees with the plan/procedure distinction only has to dismiss the 
commitment to the generic theories mentioned, possibly providing other theories that 
support a different conceptualization. 



4 The Ontology of Guidelines 

In this paragraph we present the main features of the "guidelines" ontology and 
related concepts. 
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Guidelines are distinguished in "paper guidelines" and "web guidelines". Some 
common concepts - like "author" - pertain to both of them, whereas "URL" and "last- 
checked" are peculiar of the web guidelines. 

They are also categorized in five different kinds, as defined in the Guideline 
Interchange Format standard (GLIF) [27]: "guideline for care of clinical condition", 
"screening and prevention", "diagnosis and prediagnosis management of patients", 
"indications for use of surgical procedures", "appropriate use of specific technologies 
and tests". 

Such classification is furtherly specialized by us: for example a "guideline for care 
of clinical condition" may be a "therapy assessment", a "pharmacologic therapy" or a 
"disease management". 

Figure 2 shows the relations among the basic concepts concerning guidelines. 
More specific concepts inherit these relations holding at general level. As an example, 
let us consider "diabetic patients" (concept more specific than "group", defined as any 
collection of individuals that carry a diabetic health condition). Such patients are the 
"scattered location" (this is a special location relation accounting for naive 
localization holding between distributed object, defined in the generic ontology 
"localization") of "diabetes" (a "health condition"), which is the "target" of "diabetes 
therapy" (a "medical procedure") which "has method" a given guideline. 

As far as the formal representation of guidelines is concerned, our ontology 
integrates some of the most relevant modeling efforts so far produced: notably 
PROforma [8], EON [14], Asbru [26] and GLIF [27]. It is also an evolution of a 
model previously defined in the context of the SMART system [12]. 



procedural focus 




Fig. 2. The relations among basic concepts concerning guidelines (grey arrows stand for 
composite relations); concepts belong to different ontologies in the ontology library. 

A "guideline" is a kind of "plan" which is a method of a "procedure", and it is 
represented by a "flowchart" (fig. 3). 

The concept of "flowchart" pertains to the "diagrams" ontology. It is defined as a 
set of nodes and edges like an ordinary graph with some restrictions. Every flowchart 
has a first and a last node, only four kinds of nodes are allowed: single nodes. 
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branching nodes, synch nodes and cycle nodes. Moreover the flowchart ontology 
allows for recursion, i.e. a node may be expanded into a flowchart. 

This ontology accounts for the structural part of a guideline, but no semantics for 
actions is attached to it. The semantics for the actions involved pertains to the 
planning ontology, where simple nodes represent elementary actions and branching 
nodes enquiries and decisions. The recursion allowed in the flowchart domain, where 
a node of a flowchart may be expanded into a flowchart, is isomorph to the planning 
ontology, where an elementary action may be refined into a plan. 

We believe that in our model it is appropriate to capture the distinction between the 
structural part of a guideline, represented by the flowchart, and its action semantics, 
represented by the plan. A third level is that of the procedure, i.e. what is actually 
performed. 

Figure 4 reports an excerpt from the planning ontology (the representation 
language is Loom). Such an approach can put in evidence - at formal level - the 
equivalences among the various modeling approaches. We defined the GL-mapping 
ontology in order to account for such equivalences (figure 5). 

Therefore this ontology integrates some of the most relevant work in the guideline 
modeling field. It is GLIF-compliant, i.e. each concept defined in GLIF is represented 
in it (e.g. the "synch" node after parallelization of activities). It takes into account the 
ProForma task ontology which categorizes tasks into: actions, enquiries and decisions 
and allows recursive definition of them (a plan is made of tasks, a task may be a 
plan). 



flowclurt '■) 



represents 



plan ^ ^ 
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has method 
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Fig. 3. The main concepts concerning a guideline. A guideline is a plan, and planning should 
be kept distinct from both diagrammatic representation and reference to actual procedures. 



5 Conclusions 

It has been proven that the introduction of guidelines can significantly decrease the 
costs of care and this make them a "hot topic" in the agenda of health care 
professionals. 

Guidelines are mushrooming and computers can help in retrieving them and can 
give assistance during their execution. However such a widespread diffusion poses 
new problems, not only in terms of credibility and acceptability, but also concerning 
non-ambiguity in knowledge dissemination. Formal models with a clear semantics 
should be defined in order to represent guidelines and facilitate their diffusion. 
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The definition of ontologies - i.e. the formal description of the entities to which a 
model makes a commitment and of the relations holding among the entities - is the 
groundwork for making a standard model acceptable and sharable. An ontology 
library is not normative, but allows an inter-subjective, explicit and formal agreement 
on the semantics of the primitives of a model, by referring to more generic primitives 
(generic theories). 

In this paper we presented our work in terms of the definition of an ontology of 
guidelines which is part of a larger ontology library containing both domain and 
generic theories. We believe that such an approach can facilitate the standardization 
process by allowing an explicit mapping in a formal ontology of the concepts 
represented in the heterogeneous models proposed so far. 
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(defcontext planning 

; theory (unrestricted-time diagrams meronymy) ) 

(defconcept generic-plan 

: annotations ((DOCUMENTATION "A generic plan is a script that 
contains the method for executing or performing a procedure or 
a stage of a procedure.")) 

; is-primitive ( : and script 
( ; all method 

(:or procedure procedures^stage) ) ) 

;implies ( ; and ( ; some represented-by document) 

( ; some has-component generic-plan) 

(;all component generic-plan) 

(;all serial-value serial-value-filler) 

(;all has-title symbolic-string) 

(;all has -precondition situation) 

(;all authored-by plan-author) 

(;all duration-value number) 

(;all has -description symbolic-string) 

(;all has-postcondition situation)) 

;partitions $generic-plan$) 

(defconcept elementary-plan 

: annotations ((DOCUMENTATION "A plan that does not contain 
compacted plans (ie, subplans represented by a simple node that 
can be expanded into a flow-chart) .")) 

; is-primitive 
(;and generic-plan 

(:all has-component Incoherent generic-plan))) 

(defconcept complex-plan 
;is ( : and generic-plan 

(:at-least 2 has-component generic-plan))) 

(defconcept branching-plan 

; annotations ((DOCUMENTATION "A plan that subdivides in a 
set of plans . " ) ) 

; is-primitive 
(;and elementary-plan 
(:at-least 2 plan-direct-predecessor)) 

; implies (;and ( ; some represented-by fork-node) 

( ; some method planning-transition) ) 
tin-partition $generic-plan$) 

(defconcept case-plan 

; annotations ((DOCUMENTATION "A plan branched to a set of 
plans not executable in parallel.")) 

; is-primitive 
(;and branching-plan 
(:at-least 2 plan-direct-predecessor 
(;and generic-plan 
(:at-least 1 has -precondition) 

(tall co-exist Incoherent generic-plan)))) 

: implies ( : some represented-by fork-node)) 



Fig. 4. An excerpt from the planning ontology. 
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(defcontext GL-Mapping : theory (guidelines)) 

(defrelation maps 

; is-primitive extrinsic-structuring-relation) 

(defrelation mapped-by 
;is (: inverse maps)) 

(defrelation equimaps 
; is-primitive maps) 

(defrelation equimapped-by 
;is (: inverse equimaps)) 

(defrelation partly-maps 
; is-primitive maps) 

(defrelation partly-mapped-by 
;is (: inverse partly-maps)) 

; ; ; ProForma 

(defconcept Proforma-entity 
; is-primitive (;and document 

( : some mapped-by document) ) ) 

(defconcept Proforma-task 

; is-primitive (;and Proforma-entity 

( : the equimapped-by generic-plan))) 

(defconcept Proforma-plan 
;is ( : and Proforma-task 

( ; the equimapped-by complex-plan) ) ) 

(defconcept Proforma-action-task 
; is-primitive 
(;and Proforma-task 

( : the subsumapped-by elementary-plan) 

(:all has-description symbolic-string))) 

; ; ;GLIF 

(defconcept Glif-step 
: is -primitive ( : and Glif -entity 

( ; the equimapped-by generic-plan) ) ) 

(defconcept Glif -guideline-step 
;is ( : and Glif -entity 

( : the equimapped-by complex-plan) 

(:all has-description symbolic-string))) 

(defconcept Glif -action-step 
; is-primitive (;and Glif-step 

( : the subsumapped-by elementary-plan)) 

; implies 

(;some has-description Glif -action-specif ication) ) 



Fig. 5. An excerpt from the GL-mapping ontology. 
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Abstract. Research in the ontology engineering field is becoming in- 
creasingly important, especially in the area of knowledge sharing. Many 
research efforts aim to reuse and integrate ontologies that have already 
been developed for different purposes. This gives rise to the need for 
suitable architectures for knowledge sharing. This paper analyses a spe- 
cific aspect of knowledge sharing; that is the integration of ontologies in 
a way such that different inheritance mechanisms within the ontology 
are supported, and focuses on conflicts due to multiple inheritance. We 
first illustrate the problems that inheritance can cause within ontologies 
together with different approaches presented in the literature to deal 
with multiple inheritance conflicts and then propose a semi-automatic 
approach to deal with such conflicts. 



1 Introduction 

Ontologies have become increasingly important in sharing and reusing know- 
ledge. In [26] an architecture of multiple shared ontologies for knowledge sha- 
ring was presented. In this architecture, resources no longer commit to a single 
comprehensive ontology but instead are clustered together on the basis of the 
similarities they show in the way they conceptualise the common domain: each 
cluster sharing an ontology. Ontology clusters are then organised in a hierarchical 
fashion thus permitting concepts to be described at different levels of abstrac- 
tion. Since different siblings can extend their parent cluster concepts in different 
ways the cluster hierarchy permits the co-existence of heterogeneous (sibling) 
ontologies. This approach has the advantage of minimising the information loss 
when performing translations between resources, since they communicate using 
the least abstract ontology common to them. 

The proposed structure of multiple shared ontologies is based on inheritance 
mechanisms. From studies on inheritance [2] , [24] it has emerged that anomalies 
might arise when dealing with inheritance mechanisms; research efforts in non- 
monotonic reasoning have focused on these anomalies [15], [19], [13]. This paper 
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analyses how inheritance problems can affect ontologies and proposes a metho- 
dology to deal, in a semi-automatic fashion, with the conflicts caused by the use 
of inheritance mechanisms, following the approach proposed by Goldszmidt and 
Pearl [9]. 

The proposal is to represent ontologies by an ’’enriched” frame-based langu- 
age where the set of the slot’s facets has been extended to encompass additional 
information required for a full understanding of a concept. Understanding a con- 
cept involves a number of things. First it involves knowing what can sensibly be 
said of a thing falling under that concept. This can be represented by associating 
attributes with the concept, and possible values that these attributes can take 
when applied to things of that type. Thus it is important to know that some 
birds fly and others do not. A full understanding of a concept involves more 
than this, however: it is important to know also what is true of a prototypical 
[22] instance of a concept, to know that the prototypical bird flies. There are, 
however differences in how confident we can be that an arbitrary instance of 
a concept conforms to the prototype: it is a very rare mammal that lays eggs, 
whereas many types of well known birds do not fly. Understanding a concept also 
involves understanding how and which attribute values change over time: people 
may have eyes of various colours, but they do not change over time, whereas hair 
colour does. This dynamic behaviour also forms part of the domain conceptua- 
lisation. We believe that this additional information needs to form part of the 
ontology. In this paper we concentrate on prototypical values, but also mention, 
in passing, one method of dealing with dynamic values. 

Representation of concepts within the ontology should be enriched by infor- 
mation concerning the degree of strength associated with some properties and 
some measures of how is likely that a value is associated to an attribute. We 
take these measures to be qualitative rather than numeric. This additional in- 
formation enables us to deal with conflicts and inconsistencies due to inheritance 
mechanisms, as rules with a higher degree of strength and ranking can be given 
precedence. Other facets are introduced to represent how the attribute’s value 
can change over time; this is based on the intuition that attributes can change 
their values either regularly in time or if an event occurs and that these changes 
contribute to enrich the attribute description. 

The remainder of the paper is organised as follows: section 2 describes pro- 
blems caused by different inheritance mechanisms, while section 3 presents Gold- 
zsmidt and Pearl’s nonmonotonic approach which is the theoretical framework 
we follow to deal with inheritance problems and section 4 highlights the problems 
arising when supporting multiple inheritance in the ontology representation. Sec- 
tion 5 illustrates the extended knowledge model used to apply the Goldzsmidt 
and Pearl’s approach, while section 6 sketches the framework used to deal with 
inheritance conflicts and section 7 applies this framework to a classical artificial 
intelligence example of inheritance problem: the Nixon diamond. Finally, section 
8 draws conclusions and presents future work. 
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2 Providing a Motivation for the Additional Facets 

Representing knowledge about the world means representing the objects presu- 
med or hypothesised to exist and to be relevant in the world and their relati- 
onships. It has been argued that a knowledge representation is a surrogate [5], a 
stand-in, for what is in the world. Like any surrogate it is not completely accu- 
rate; it will necessarily contain simplifying assumptions because of the comple- 
xity of the natural world. Indeed even restricting to a subset of the natural world 
is still overwhelmingly complex. In this respect, a knowledge representation is 
also a set of ontological commitments. Ontological commitments determine not 
only the objects of the world but also what are the features of these objects that 
are relevant for the knowledge representation task. 

Objects correspond to classes: all the member of a class share some common 
properties. Classes represent concepts (the terms can be used as synonyms). 

The set of relevant concepts and the relationships holding between them form 
the conceptualisation [8] used to represent the world. When selecting a concep- 
tualisation of the world some decisions have to be made in order to establish 
what concepts to describe and how to describe them. Concepts are identified by 
sets of attribute-value pairs, where the attributes are those deemed important 
for the knowledge representation task and the values associated with them per- 
mit us to distinguish one concept from another. Usually in the conceptualisation 
are also represented properties that are generally true for that concept, that is 
the conceptualisation usually describes a prototypical member of that class [22] . 
This gives rise to an important issue in knowledge representation: properties that 
are true for a class prototype are not necessarily true for all members of the class 
represented by the concept. Examples of such cases are frequent in everyday life; 
Almost all mammals give birth to live young, but three highly unusual mammals 
(monotreme) do not. Analogously, the ability of birds to fly is a property that 
is generally true; it is a property describing the prototypical bird. This type of 
information on the descriptive strength of properties should be encompassed in 
the conceptualisation of the domain and thus in the ontologies derived from it. 

An ontology is ”an explicit specification of a conceptualisation” according to 
Gruber [10]. That is, the conceptualisation refers to an abstract model of some 
phenomenon in the world by identifying the concepts that are relevant to that 
phenomenon; in the ontology, the type of concepts used to describe the phe- 
nomenon and the constraints on their use are explicitly defined [23]. Ontology 
representations should include ways to represent how generally a property is sha- 
red among the members of a class. The ability of ontologies to distinguish not 
only between hard statements like ’’Elephants are animals” and soft ones like 
’’Birds fly”, but also between degrees of ’’softness”, is crucial for reasoning ab- 
out the knowledge represented in the ontology. This reasoning can prove helpful 
in dealing with problems arising from of the hierarchical organisation of con- 
cepts in ontologies. Concepts in ontologies are hierarchically organised through 
an IS-A relationship, with a partial order relation that is the ontology’s main 
structure and that is further enriched by attributes, and by relationships or 
functions relating concepts. The IS-A relationship introduces also the powerful 
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notion of inheritance of properties. Properties are shared by concepts either in 
their original form or modified in order to give the inheriting class, known as 
subclass, a more restrictive definition than that provided by the parent concept. 
Furthermore other properties can be added to form more specialised concepts. 

Anomalies arising from inheritance mechanisms have been illustrated in the 
literature ([2] and [24]), where a distinction is made between single inheritance 
and multiple inheritance. The former permits a concept to inherit properties 
from one parent only and can cause default conflicts while the latter permits 
a concept to inherit properties from more than one parent and can cause in- 
consistencies in inherited attribute values. In [3], default values are defined as a 
way to deduce information about a concept if the information is consistent with 
what is already known about the concept. Reasoning about defaults can became 
extremely problematic when only strict inheritance is allowed, that is when the 
IS- A link amounts to logical implication or set inclusion. Then, more specific in- 
formation cannot overrule information obtained from more general classes thus 
causing wrong conclusions to be inferred. A defeasible approach [24] permits the 
more specific information to overrule the more general one“ thus solving the 
conflict. 

Other kind of conflicts can arise when multiple inheritance is supported and 
conflicting information is inherited from two or more general concepts. In this 
case a choice has to be made about which value has to be associated with 
the attribute. This choice can be made by knowledge engineers, or the value 
can be (semi) automatically provided by determining the property’s degree of 
’’softness”. The same inconsistency problems caused by supporting multiple in- 
heritance can be encountered when trying to integrate ontologies developed for 
different purposes (the word integration is used here to summarise all the pos- 
sible meanings that the term takes in the ontological engineering field, and that 
are illustrated in [20]). In fact, with ontology integration an attempt is made to 
relate concepts in different ontologies. Concepts to relate can be described by 
the same attributes, but inconsistent values may be associated with them. So, 
when integrating ontologies, a crucial issue is to choose, among the inconsistent 
candidates, the value to associate with an attribute. An example of problems 
encountered while trying to integrate two or more ontologies can be found in 
[7] and [6]. Once again, the choice is made by the knowledge engineers perfor- 
ming the integration who can be assisted by some tool that (semi) automatically 
chooses the most promising attribute’s value among a set of candidates. 

Before proceeding with the discussion, we would like to clarify a point: most 
of the classical example of default inconsistencies, such as Tweety the penguin 
or the Nixon diamond concern instances instead of concepts. However, all the 
considerations that have been made for the instances still hold true also for clas- 
ses, as we can semantically overload the IS-A relationship with the meaning of 
Instance-of relation. We are aware that such an attitude has been strongly criti- 
cised in the literature [27], but we deem that such a difference can be disregarded 
when considering multiple inheritance. 
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It is interesting to note that the conflicts do not only arise when the IS-A 
relationship is explicitly stated; in fact conflicts as the Tweety triangle can as 
well occur in cases of feature inheritance. The Tweety triangle can be easily 
reformulated as Concept: Bird, Feature: Flier =” yes” etc.; in this case also the 
conflict for Tweety arises. 

Other kind of conflicts can arise when the knowledge representation system 
allows multiple inheritance and conflicting information is inherited from two or 
more concepts. The typical example of such a situation is the Nixon diamond. In 
this case, however, we are not able to infer any conclusion, not even the wrong 
one. 

3 Reasoning with Conflicts 

Both inheritance with exceptions and multiple inheritance default conflicts have 
been widely investigated in the literature concerning inheritance networks. Se- 
veral approaches have tried to infer a reasonable conclusion (if not the right one) 
from conflicting premises. Horty in [12] divides theories of inheritance into direct 
and translational theories. Direct theories are those where the properties and 
the features of the inheritance networks (such as consistency) along with the set 
of conclusions that can be inferred from the premises are analysed and characte- 
rised in terms of the networks formalism itself. Examples of direct theories can 
be found in [24], [13], and [12]. 

Translational theories are those where the meaning of an inheritance network 
is specified in terms of some type of logical language, either classical first order 
logic, or some nonmonotonic logic such as Circumscription [15], or Default Logic 
[21]. This section focuses mainly on direct approaches. Among the direct ap- 
proaches here we mention the approach by Pearl [19] and lately by Goldszmidt 
and Pearl [9] as being particularly relevant for dealing with multiple inheritance 
within ontologies. The main idea of this approach is that knowledge from an 
inheritance network can be associated with a probability expressing the degree 
of (dis)belief associated with that bit of knowledge. This measure of the degree 
of belief permits the approach to handle more complex default interactions (such 
as inheritance with exceptions) correctly, as pointed out in [1]. 

More formally, given the language L of the inheritance network (that for 
Pearl is the language of propositional formulas), every sentence in L corresponds 
to a set of possible worlds, where a world is a conjunction of all the properties 
describing a typical individual in the domain. As some worlds are definitely 
more typical than others it is necessary to express the differences between all 
the possible worlds. This is obtained by weighing every world by assigning it a 
probability e, which defines a probability distribution P over L. All the inhe- 
ritance rules such as Elephant(x) — >■ Animal{x) impose restriction conditions 
on P in the form of extreme conditional probability infinitesimally close either 
to 0 or to 1, where the closer to 1 the probability, the higher the number of 
subclasses (and eventually individuals) inheriting the property. So, if we consi- 
der the inheritance rule Mammal(x) — >■ Gives-birth-to-live-young(x), this means 
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P(Gives-birth-to-live-young(x)\Mammal(x)) > 1 — e that for e arbitrarily small 
is close to 1, meaning that if all is known is that a; is a mammal, than x almost 
certainly inherits the property of giving birth to live young. 

However, the full precision provided from this framework is not necessary for 
taking decisions on inheriting conflicting default values. Under this assumption 
Goldszmidt and Pearl measure the degree of belief not in the continuous interval 
[0, 1] but rather on a logarithmic scale and they consider beliefs that map into 
two different values as being of different order of magnitude. 

Let P{uj) be the probability distribution defined over a set Q of possible 
worlds; if we write the probability P{u)) as a polynomial in e (that is Pe(w) = 
1 — ci£, or — C 2 £^ and so on) then the ranking function /t(o;) is defined as 
the power of the most significant £-term in Pgiuj). That is the ranking P{oj) is 
expressed as some power of a parameter £ which plays only the role of linking 
the defaults together. Letting £ — >• 0 means that the defaults tend to be certain. 

The ranking k permits to reason about both ’’hard” and ’’soft” statements; 
’’Birds fly” is, for instance, a soft one because it is typically true for most of 
the subclasses of the class Birds. The rank n roughly corresponds to linguistic 
quantifiers such as believable, unlikely, very rare etc. In fact for k(</>) = 0 it 
means that both (j) and -«j) are equally possible, for «:(</>) = 1 it means that -<4> 
is believed, for «;(</>) = 2 it means that -i</> is strongly believed, for K{(j>) = 3 it 
means that -i(() is very strongly believed and so on. 

An inference system {Z-system) based on the ranking of probabilities has 
been developed in [9]. The Z-system is able to draw plausible conclusions in 
most of the cases by a technique known as z-entailment, [9] which guarantees 
that conclusions in inheritance rules will receive high probabilities whenever the 
premises receive sufficiently high probabilities. This system can compute the pri- 
orities of inheritance rules and provides also consistency checks. Unfortunately, 
one of the main drawbacks of the z-entailment is that it cannot sanction the 
inheritance property from classes to subclasses with exceptions. This happens 
because the z-entailment labels all the classes with exceptions as exceptional in 
all respects, so that they become unable to inherit any of the properties that are 
typical of their parent class. To overcome this drawback the authors introduce 
the capabilities for a Z-system to handle variable-strengths thus allowing some 
defaults to be stated ’’more strongly” than others. 

The system — [9] extends the specification of the inheritance rules by 

associating with each rule a parameter 6 which expresses the degree of strength 
of the rule. Inheritance rules are now ordered on the grounds of a priority fun- 
ction which is computed as function of both the ranking associated with 
an inheritance rule and the degree of strength 6; each of them reflects different 
considerations to be taken into account when drawing conclusions about inhe- 
riting properties. The degree of strength 6i associated with an inheritance rule 
Ti = 4>i ^ V’i establishes the relative strength with which 'ifi is committed to be 
accepted in the context of (fi while the priority Z^{n) expresses the degree of 
surprise concerning the finding of a world that violates r^, which includes also the 
degree of surprise associated with (fi. Again all the consistency considerations 
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hold also for the system — . Therefore now for each rule Vi = 4>i ^ ipt the 

ordering is determined by both the degree of strength and the ranking function. 
This type of ordering guarantees that features of more specific contexts override 
conflicting features of a less specific order, thus allowing the well known Tweety 
the Penguin problem to be solved. Furthermore, whenever the ranking functions 
associated with the rules do not permit us to distinguish between inheritance 
rules, because no specificity consideration is made, the ordering depends on 
the degree of strength alone, therefore permitting preference of one inheritance 
rule over the other(s). In this way the system can deal with types of conflicts 
such as the Nixon diamond. 



4 Ontologies and Multiple Inheritance 

Latest research on inheritance has focused on extending the basic framework of 
single inheritance without exceptions to inheritance with exceptions and multi- 
ple inheritance. However, research on these issues has mainly been confined to 
academia, giving the impression that problems such as multiple inheritance and 
inheritance with exceptions are quite rare in real applications [18]. 

Research in the ontology field has not yet considered any of the problems 
due to the inheritance of conflicting default values. Indeed many languages to 
represent ontologies support either multiple inheritance or inheritance with ex- 
ceptions, but often they do not have any mechanism to deal with the problems 
caused by these formalisms. Possibly, the problem of handling conflicts has not 
been regarded as such because ontologies have been usually written from scratch 
whenever they were needed. This trend in the ontology field has been changing 
recently, mainly due to research in ontology engineering, which has stressed the 
importance of building ontologies that are reusable and sharable. 

When trying to integrate ontologies developed for different purposes, incon- 
sistencies can arise ([7] and [6]). In fact, one concept can have different parents 
in different ontologies, and those parents can be described in terms of conflicting 
attributes. The situation can be even more complicated because inconsistencies 
can be implicit. Inheritance literature has not been extensively discussed in this 
context although it is extremely relevant in ontology merging. Indeed, it is likely 
that ontologies built for different purposes and then merged represent concepts 
in terms of attributes that are semantically equivalent although with mismat- 
ches in the names [25]. Morgenstern [18] has modified the Touretzky’s Nixon 
diamond [24] to show how inconsistencies can be also implicit. The new Nixon’s 
diamond example is shown in figure 1. 

The two concepts Quaker and Republican are described by two attributes 
Pacifist and Hawk that have different names but are semantically related (one 
is the opposite of the other), as they both describe someone’s attitude towards 
going to war. The proposed framework, illustrated in the next section, deals with 
such types of inconsistencies. 

From the inheritance network viewpoint, ontologies are mixed inheritance 
networks, where both strict and defeasible paths are allowed, therefore, when 
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Fig. 1. The modified Nixon diamond 



trying to reason with the knowledge expressed in the ontology, an inference me- 
thod that is able to deal with both types of path is needed. Unfortunately most 
of the ontologies are based on frames representation systems such as the Generic 
Frame Protocol [4] where no slot’s facet is used to distinguish between these 
paths. This is the reason why we propose to augment the typical facets of a 
slot by introducing some additional pieces of information which are useful in 
dealing with default and inheritance problems: the ranking associated with the 
inheritance rule, a degree of strength associated with the attribute and facets 
about how the attribute’s value can change over time. The ranking expresses the 
degree of belief which is associated with the inheritance rule expressed by the 
attribute, that is how surprising is to find out that, for the concept that is being 
described, the attribute takes a particular value. In our approach the degree 
of strength is associated with the attribute (and therefore with the inheritance 
rule) by the knowledge engineers who are either writing or merging the ontolo- 
gies, as these people should be familiar with the domain and should therefore 
be able to weight inference rules. The degree of strength not only distinguishes 
between strict and defeasible links, but can also be used to measure the degree 
of defeasibility. Moreover, it permits us to establish preferences among defaults 
when no specificity considerations are available. If we consider the Nixon dia- 
mond example, both facts A: ’’Quakers are pacifists” and B: ’’Republicans are 
not pacifists” are absolutely true, but they might be evaluated differently depen- 
ding on the domain and even on specific circumstances. A degree of strength can 
be associated with both these rules. Let us assume that the knowledge engineer 
believes that religious convictions carry more weight than political affiliations, 
than the degree of strength associated with A, <5^ is greater then the degree of 
belief associated with B 8 b - So when the value of the attribute Pacifist is deter- 
mined for the object Nixon, whenever no specific information on the object is 
available, the degree of strength makes it infer that Nixon is a pacifist. 

Although the degree of strength is decided by the knowledge engineer, it can 
be affected by specific events that can change the status of an attribute. The 
intuition behind this is that nonmonotonicity is either time dependent or event 
dependent, meaning that the value of an attribute can change regularly in time 
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or it can change if a particular event occurs. Therefore, in case of conflicting 
default values the choice among the possible values should be made by taking 
into account the regularity in time or the occurrence of one of the modifying 
events. Going back to the Nixon example, one of the events that can change the 
status of the attribute Pacifist is the declaration of a war: as president of the 
United States, although maybe personally inclined to be pacifist, Nixon would 
tend to protect the interests of his country in the event of a conflict, and so in 
such a scenario he would not act as a pacifist. This can also mean that until a 
war is not declared we can assume that the degree of strength associated with 
the religious conviction is stronger than the one associated with the political 
conviction, but in case of war this would be no longer true. 

Finally, it is interesting to note that many problems with multiple inheri- 
tance could be solved by a more careful design of ontologies as pointed out by 
Guarino [11]. This is due to the fact that in many cases the IS- A relationship is 
used to represent many other specialised links such as reduction of sense, over- 
generalisation, confusion of senses, clash of senses, and sometimes some kind of 
type-to-role links. 



5 The Extended Knowledge Model 

So far, all the efforts to deal with inconsistencies have been performed by hand by 
a knowledge engineer who is expert in the domain that is being described, and 
who can thus associate the correct default value with an attribute. Ghoosing 
between several conflicting defaults requires an extremely rich semantics. For 
this reason performing the choice automatically is quite unrealistic, but a more 
realistic possibility is a semi-automatic approach, where an inferential system 
presents the knowledge engineer with a list of sound alternatives (according to 
the inference process), but leaves the actual choice to the knowledge engineer. 

The model of knowledge used to represent the ontology plays a crucial role 
in the framework proposed in this paper, as it provides the elements necessary 
to apply the Goldszmidt and Pearl inference process. The proposed knowledge 
model is frame-based [17]. Our model is based on classes, slots, and facets. Classes 
correspond to concepts and are collections of objects sharing the same properties, 
hierarchically organised into a multiple inheritance hierarchy, linked by IS-A 
links. Glasses are described in terms of slots, or attributes, that can either be 
sets or single values. A slot is described by a name, a domain, a value type 
and by a set of additional constraints, here called facets. Facets can contain the 
documentation for a slot, constrain the value type or the cardinality of a slot, and 
provide further information concerning the slot and the way in which the slot is 
to be inherited by the subclasses. Our framework suggests the introduction of a 
set of facets that describes in detail the attribute and its behaviour in the concept 
description to accommodate different inheritance mechanisms, both within and 
between ontologies, and changes over time. This additional information is to 
be used in case of inconsistencies as a guide towards the most reasonable and 
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informed suggestion to be presented to the domain expert, who will than validate 
such suggestion. The facets we introduce are: 

— Value: There are three possibilities: 

— If the concept that is being defined is very high in the hierarchy (so high 
that any distinction based on the attribute’s value is not possible), then 
Value is equal to Domain; 

— If the concept is still general, but it is possible to determine that it can 
have different attribute values for its children then Value is set equal to 

Sub-domain C Domain; 

— If the concept is defined in terms of a specific value for an attribute then 

Value is set v G Domain. 

For the third case only, further information about the type of value (see next 
item) or the degree of strength (see item below) can be added; 

— Type of value: {Necessary, Prototypical, Inherited, Distinguishing}. An 
attribute’s value is a Necessary one if the value is true for all concept’s 
children. It describes necessary conditions in the concept’s description. An 
attribute’s value is a Prototypical one if the value is generally true for any 
children of the concept that is being defined, that is the value is generally true 
for any prototypical instance of the concept, but exceptions are permitted 
with a degree of softness expressed by the facet Ranking. An attribute’s value 
can be Inherited from some super concept or it can be a Distinguishing value, 
that is a value that differentiates among siblings; 

— Degree of strength: a number describing how relevant is, in the concept’s 
description, the property represented by the attribute. For example, to rea- 
son about birds ability to fly, the attribute species is more relevant than 
the attribute feather colour. In merging ontologies this facet represents the 
weight associated with the inheritance rule corresponding to the attribute; 

— Ranking: an integer describing the probability ranking associated to the 
fact that the attribute takes the value specified in the facet Value. The 
possible values for this facet are 1: All, 2: Almost all, 3: Most, 4: Possible, 5: 
A Few, 6: Almost none, 7: None. So, to represent the soft statement Birds 
fly we could describe the concept Bird by a slot. Fly that takes value Yes 
with Ranking equal to ’’Most”; 

— Change frequency: [Regular, Once only. Volatile}. This facet describes 
how often an attribute’s value changes. If the information is set equal to 
Regular it means that the value changes at regular time intervals; if set 
equal to Once only it indicates that only one change is possible, and finally 
Volatile indicates that the attribute’s value can change more than once. If 
the change frequency is Regular then the time interval is specified otherwise 
the event causing the attribute to change is specified; 

— Time interval: This information can either be empty (if the change fre- 
quency is not Regular) or it contains the time interval between two changes; 

— Event: This facet is either empty (if the change frequency is Regular and 
the time interval is set) or it is the set of events E that causes a change in 
the attribute’s value. The logical theory chosen to reason about events is the 
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Event Calculus [14], and the information Event^Ci is interpreted as one of 
the following Event calculus expressions: 

1. Hold (before (ci, P)) that is, the property P holds BEFORE the event e*; 

2. H old (after (ci, P)) that is, the property P holds AFTER the event e*; 

where the interpretation is decided on the information Event Validity (see 
below). For each event Ci € E we specify also the Event Property and the 
Event Validity facets as follows: 

— Event Property: {V}. This facet describes the value taken by the 
attribute before or after the event E. If this bit of information is empty 
it means that the event E causes a change in the attribute’s value that 
cannot be specified, possibly because the value can be identified only by 
considering the instances of the concept; 

— Event Validity: {Before, After}. It states whether the property V spe- 
cified in the item above holds before the event E or after the event E. 

The above facets describe how crucial the slot is in characterising a class, and 
what conditions determine a change in the value of the slot for that class. These 
changing conditions are used to query the knowledge engineer while solving 
default inconsistencies to try to associate with a slot a value as close to the true 
one as possible. These facets could also be used by knowledge engineers to learn 
more about the attribute they are dealing with. 

6 The Framework to Deal with Inheritance Conflicts 

When dealing with heterogeneous resources, mismatches in the names of con- 
cepts and attributes might occur [25], [6]. The first step of our framework con- 
sists of resolving name mismatches following [7]. This is necessary to avoid cases 
of implicit inconsistencies, where attributes describing two parent concepts are 
denoted with different names, while describing the same property. Then the 
attempt to relate the concepts in the ontologies composing the structure can 
begin. 

In the remainder we present the steps composing this framework, explaining 
how a system can resolve inconsistencies when trying to build multiple shared 
ontologies. Ontologies are assumed to be represented by the knowledge model il- 
lustrated above. The knowledge engineer KE interacts with the system in several 
steps: 

— The first step of our framework consists of scanning both the class names and 
the slot names in all the ontologies to find possible synonyms. Synonyms are 
evaluated intensionally, selecting them on the basis of a general thesaurus 
such as WordNet [16]. For the attributes, however, also an extensional check 
is performed, by checking the similarity in the attribute’s domains. 

— Once the name mismatches are resolved, the system proceeds both bottom- 
up and top down trying to relate classes. When it finds two or more classes 
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that are suitable parents for the class the system is handling, then a con- 
sistency check is performed, according to the technique by Goldszmidt and 
Pearl [9]; 

— If an inconsistency is detected then the priority functions (see section 3) 
for the inheritance rules are computed on the grounds of both the rankings 
of probabilities and the degrees of strength. These facets permit to solve 
both default conflicts and inconsistencies due to either multiple inheritance 
or to the integration of diverse ontologies. The slot’s facets encompassing 
information about the events that can cause the attribute to change are 
taken into account too, as this information is presented to the KE who is 
requested to validate the events. The system should have now everything 
necessary to compute the priority function: if so it proceeds to the next 
step, otherwise if either the ranking or the degree of strength are missing, 
the systems asks the KE to insert them. The value of the inserted facet is 
decided on the grounds of the information regarding the attribute’s changes 
over time. 

— After all the priority functions are computed and ordered, the system pre- 
sents the KE with the slot’s value with the best scores. 

— The KE decides whether to accept the system suggestion or to ask the 
system to present the list of possible choices in rank order. 

7 Applying the Framework to the Nixon Diamond 
Problem 

To explain more clearly how the proposed approach works let us consider the fol- 
lowing example, which is an extension of the Nixon diamond. Let us suppose that 
we need to model the beliefs of the US population from two different viewpoints: 
political affiliations and religious convictions. The two ontologies describing these 
viewpoints are partially illustrated in figure 2. These different viewpoints do not 
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pacifist = no 
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Fig. 2. Sections of the two ontologies modeling the beliefs of the US popnlation 



always contrast in the process of taking decisions because one of them often pre- 
vails, depending on the matter: political affiliations usually determine people’s 
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positions on issues such as welfare and economics whereas religious convictions 
affect moral issues. However there are some controversial issues that have also a 
strong moral component, therefore both viewpoints contribute to the process of 
decision making. In such cases the two viewpoints can either agree or contrast 
so in this latter case a choice is necessary. 

In this example we consider two ontologies, one modeling the political affi- 
liations of US citizens and the other the religious convictions: the two ontologies 
need to be merged to use this knowledge in order to take decisions about pu- 
blic interest issues that can be considered from both a political and a moral 
viewpoint. 

In merging the two ontologies the following inheritance rules hold for the 
class ’’Nixon”: 

ri: ”quakers are pacifists with strength 6i”, q p 
r2- ’’republicans are non pacifists with strength 62”, r -ip 
r^: ’’quakers are against death penalty with strength 63 ”, q -•d 

r4'. ’’republicans support death penalty with strength 64”, r d 

Let us suppose we want to use the knowledge in these two ontologies to infer 
what would be the position of Nixon in two different situations: going to war 
and voting on the death penalty. These are decisions that might be taken on 
the grounds of both political and religious beliefs. Therefore we try to apply 
the algorithm sketched in the previous section to merge the two ontologies in 
this two cases. Let us start from the situation in which Nixon has to decide 
whether the US should go to war. In both these examples we are not concerned 
with problems due to name mismatches, so we assume that the first step of the 
procedure is executed successfully. Then the system attempts to relate classes; 
it finds the class Nixon in both ontologies and with a different parent in each 
ontology, so the system considers the class Nixon as child of both the class Quaker 
and Republican, thus inheriting attributes from both of them. At this point the 
system detects an inconsistency, therefore it tries to resolve it by considering the 
rankings of probability and the degrees of strength associated with rules r\ and 
f2- 

In such a case, as also pointed out by Goldszmidt and Pearl [9], the 
system is not able to decide which rule to prefer on the grounds of the ordering 
alone, because the priority functions associated to the rules by the system 
are: Z+(ri) = i5i and Z+(r2) = <52- In fact in this case the decision to prefer 
one rule over the other does not depend on specificity considerations but rather 
on the weight that is associated with each inheritance rule and that depends on 
the task at hand. In problems such as the Nixon diamond it is likely to find that 
the degree of strength associated with the inheritance rule is is left as choice to 
knowledge engineers. Knowledge engineers use their knowledge of the domain to 
assign a value with the degree of strength for each inheritance rule. However, the 
facets concerning the events causing the attribute’s value to change can provide 
additional information to the process of making a decision. In this specific case 
the event causing the attribute Pacifist to take value No for any child of the 
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concept Republican in the ’’Political Affiliation” ontology is the threat of a war 
against the USA, that is in terms of event logic Hold(after(War-Against-USA, 
Pacifist=No)). So, when the knowledge engineers merging the two ontologies 
decide the values of the degrees of strength, the choice is made on the grounds 
of the available information. Since it is in the ’’Political Affiliation” ontology that 
the attribute which is being handled is described as changing its value if a war 
occurs, then this inheritance rule prevails. So, knowledge engineers set <52 > i^i- 
The system returns the Z~^ ordering r2,ri, thus solving the conflict by preferring 
the rule republicans are non pacifists over the rule Quakers are pacifists. 

In the other situation, that is deciding over death penalty, the algorithm 
works pretty much in the same way. In this case the class ’’Nixon” inherits 
both the rules rs and C4, thus the system detects an inconsistency. In this case 
no event is specified as able to change either attribute’s values: in general the 
position taken on the death penalty is a fixed opinion. However, for this example 
the probability of finding that a quaker is against death penalty is higher then 
the probability of finding that a republican is against it, since it is always true 
that a quaker does not approve death penalty whereas it is only likely that a 
republican approves it. This difference is reflected by the ordering of the 
two rules, which is: Z~^{r3) > Z~^{r4). Moreover, if knowledge engineers wish 
to encompass the information that, in case of death penalty, Nixon’s religious 
conviction carry more weight than Nixon’s political affiliation, they might set 
J3 > S4. The system returns in any case the Z~^ ordering of the rules, which is 
T3,r4, thus solving the conflict by preferring the rule Quakers are against death 
penalty, as considerations on the degree of belief prevail in this case. 



8 Conclusion and Future Work 

This paper has presented a semi-automatic framework to deal with multiple inhe- 
ritance inconsistencies while integrating ontologies. After analysing the problems 
that are classically proposed in the multiple inheritance literature, we have pre- 
sented a formal approach to deal with inconsistencies. This approach has been 
chosen to deal with inconsistencies in the ontology representation. Inconsisten- 
cies in ontologies can be more subtle than the ones in semantic networks because 
diverse ontologies can use different names for the same concept or attributes, so 
that some inconsistencies can be implicit. 

This framework is based on a knowledge model that extends the usual frame- 
based model in order to associate with each attribute a degree of strength and 
other information concerning the behaviour of the attribute. By means of this 
framework knowledge engineers trying to integrate different ontologies are now 
provided with a tool that checks the inconsistencies and presents them with a 
list of suggestions that are evaluated according to a priority function, instead 
of having to check inconsistencies by hand and resolve them. The final choice is 
always left to the knowledge engineers, but the system provides them with a set 
of possible choices and with information concerning how and when the attribute 
changes. 
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One crucial issue is the choice of the degree of strength to be associated 
with a slot. At the moment the choice on the degree of strength for inheritance 
rules is left to the knowledge engineer, although the possibility of increasing the 
degree of strength of a slot if an event causing the attribute to change occurs 
will be investigated. Future work will concentrate on extending the framework by 
introducing some form of temporal reasoning based on event logics that extend 
the facets. 
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Abstract. Designing a terminological knowledge base consists in collecting 
terms and associating them to their definition. Our objective is to define a process 
model to support this design task in a collaborative work environment. The pro- 
posed concept model is based on terminological logic and the issue-based model 
IBIS. The terminological logic part is intended to formally express definitions 
and associate them to terms and points of view. The process model we define is 
based on a cyclic conflict resolution process. It includes a formal concept com- 
parison operation, to highlight definition conflicts and their nature, and other op- 
erations (derivation, intersection, union, etc.) to solve the detected conflicts. The 
IBIS part of the model enable users to express and record issues, positions, argu- 
ments and endorsements that occur during conflict resolution. 



1 Introduction 

1.1 Background 

Terminology is about identifying, describing and naming a field’s concepts. Terminol- 
ogy’s basic elements are: concepts, terms, definitions and fields. A concept is described 
by a definition and is named by a term. As a rule, a term can only refer to a single con- 
cept within a field. The elaboration of terminological dictionaries and concept bases is 
generally intended to make translators’ job easier or to ensure a better communication 
between field’s specialists. In the recent years it has become obvious that this termino- 
logical work is crucial in information systems design and particularly in knowledge 
management. 

Everyone has his own perception of real world’s objects. Thus, when a group of peo- 
ple is building up a concept base or an information system, its members often don’t 
agree on the meaning of the terms, i.e. there are vocabulary conflicts. Surprisingly, al- 
though there are many types of concept bases, none of them allows, as far as we know, 
to store and manage multiple, not necessarily coherent, points of view for a concept’s 
definition. As a result, the choice of a definition or a term must usually be done before 
it can be inserted into the concept base. So we can say that concept models only allow 
to store the conceptualization’s result but don’t directly support the conceptualization 
process. 
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1.2 Related Work 

Traditional terminology banks, such as Eurodicautom (European Union), Termium 
(Canada), Lingua-PC (Switzerland, Canton of Bern) or BD-TERM (University of 
Geneva) [7], [15] represent a first type of concept bases. Concepts are described using 
textual definitions and other terminological descriptors (synonym, context, source, 
note). In these terminology banks it could be possible (even if it is not usually done) to 
store multiple points of view, for instance several definitions for a concept, because the 
record associated with each term is typically stored as formatted text. But as concept 
representations are not formalized, it is difficult to apply automatic processing on them. 

In terminological knowledge representation systems, (KL-ONE [2], ALCNR [4], 
etc.) concepts are characterized by a a set of roles which link them to other concepts in 
the base. In this case, definitions are not textual but formalized, thus allowing some au- 
tomatic processing. Nevertheless, in this case we have to face the opposite problem: it 
is not possible, with this kind of formalism, to handle several definitions for a single 
concept. 

The ConcepTerm model [1], [17] is relatively close to classic terminological knowl- 
edge representation systems. Concepts are defined by a set of pairs <characteristic; val- 
ue>. The goal of ConcepTerm was to enable the search for equivalent terms in different 
languages by comparing related concepts’ definitions. This can give interesting sugges- 
tions on how to compare concepts, but this model does not allow to store several defi- 
nitions for a concept. 

The Co4 system [9] suggests an interesting approach for the collaborative building 
of a consensual knowledge base from several individual bases. The bases are organized 
in a tree in which leaves are the individual bases and each node represents the consen- 
sual base of the subtree. The tree’s root is the global consensual base. With Co4, the rule 
is: before inserting a piece of knowledge into a consensual base, one must be sure that 
all the bases of the subtree agree with it. Co4 is a kind of multi point of view system: 
knowledge in a consensual base is not the same as knowledge in individual bases. It is 
however difficult to have a global view, since the different points of view are dispersed 
in several bases. 

Collaboratively designing and building a concept base can also be seen as a decision 
making process: for each concept and each point of view it is necessary to choose one 
definition among those which are suggested by the group members. There exist several 
models for decision making support in an argumentative environment, such as IBIS [5], 
[6], [12], [13] QOC and DRL [3], [18]. This kind of models will give us a basis for the 
creation of a multi point of view concept model. 

When several points of view are available, it could help to have tools for comparing 
and manipulating them. So, as we are mainly interested in managing multiple points of 
view for concepts definitions, we have to quote the works of Shaw and Gaines on con- 
ceptual systems comparisons [16]. Since the method of Gaines and Shaw aims at com- 
paring two or more different conceptual systems, it takes into account object names, at- 
tributes and values. For instance, it can compare attributes values even if the attributes 
names do not match. 

Table 1. explains some of the terms that we will use later. It is excerpted from [16] 
and indicates the possible situations resulting from the comparison of two ore more con- 
ceptual systems. 
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Table 1. Conceptual Systems Comparison Results (excerpted from [16]) 





Terms 


Same 


Different 






Consensus 


Correspondence 




Same 


People use the same terms to 


People use different terms to 


Concepts 




name the same concepts 


name the same concepts 






Conflict 


Contrast 




Different 


People use the same terms to 


People use different terms to 






name different concepts 


name different concepts 



One can remark that Shaw and Gaines’ method is meant to compare two or more dif- 
ferent conceptual systems, whereas our main preoccupation is what to do with one in- 
coherent system, build collaboratively. Their method will nevertheless give us sugges- 
tions on how to define our concepts comparison operation. These remarks are also ap- 
plicable to the method presented by Dieng [8] for modeling knowledge of multiple 
experts. (This method is based on the comparison of conceptual graphs.) It is also worth 
noticing that using differents terminologies doesn’t inevitably imply a contrast: maybe 
people just have a different level of abstraction. 

1.3 Multiple Points-of-View 

The KRL, LOOPS, ROME, VIEWS and TROPES [14] models propose different kinds 
of solutions for the management of multiple points of view. However, these models all 
rely on the hypothesis that points of view are partial representations of a unique coher- 
ent set of objects. We focus on another situation: when building the concept base, each 
person (or group of people) has his own incomplete perception of the field; the sum of 
all individual perception giving an incoherent representation of that field. This differ- 
ence between basic hypothesis stems from the fact that the model we are presenting in 
this paper is meant to support group knowledge acquisition and building whereas the 
others are more adapted to a collective use of already build knowledge. 

We consider point of view as a mean to solve definition conflicts. Namely, when two 
definitions are proposed for the same term, the multi point of view approach allows to 
keep both definitions, provided they belong to different points of view. For example, it 
would be easy to accept that a cashier and a mathematician do not define the concept of 
addition in the same way. Since we do not consider points of view as partial represen- 
tation of a unique definition, we can even accept definitions which are not completely 
compatible. This is to reflect the fact that there is generally no strict border to the exten- 
sion of a concept. For instance, where is the border between red objects and brown ob- 
jects? Nevertheless, it is clear that the definition must not be contradictory. In addition, 
points of view are not intended to hide the conflicts and to please each participant, they 
must in fact correspond to a real application (e.g. sales, engineering, accounting) or 
group of users of the knowledge base. 

1.4 Organization of this Paper 

The rest of this paper is organized as follows. Section 2 presents the ConceptIBIS mod- 
el. Section 3 introduces the concept comparison and derivation operations which will 
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be used in the conflict resolution process. Section 4 presents the conflict resolution pro- 
cess. And Anally, section 5 gives a conclusion. 



2 The ConceptIBIS Model 

When building a terminological concept base, two essential yet reciprocal problems oc- 
cur: How to deflne the concept corresponding to a term? What term to use to name a 
concept with this or that definition? When a group of people is building a terminological 
concept base, it can lead to several situations corresponding to these two types of prob- 
lems. Specifically, there can be: 

• several different definitions for a single term 

• several different terms for a single definition 

The main goal of the ConceptIBIS model is to provide a background for I) highlighting 
the above-mentioned situations and 2) solving these situations in a multi point of view 
context. The resolution of a definition conflict can lead to several situations: the two def- 
initions are accepted and each one is linked to a different point of view; or one tries to 
create a single definition from the two conflicting ones; or one accepts that there are in 
fact two different concepts (for instance if the definitions are contradictory). 

2.1 Structure of the Model 

ConceptIBIS is based on ConcepTerm. An argumentative part based on IBIS has been 
added to enable the management of multiple points of view. The purely terminological 
part of the model consists of concepts, terms, definitions, fields, and points of view. A 
concept definition comprises a set of characteristics with their respective values, the 
structure of a definition will be detailed in the next section. 

Since a concept is an abstraction, a mental representation of real object, it doesn’t 
have a material existence. Thus it must always be associated to either a term of a defi- 
nition that represent it. This fact is represented in the model by associations between the 
classes Concept and Term, and Concept and Definition. In order to implement the multi 
point of view approach, each definition must be attached to at least one point of view 
on the concept’s field. Furthermore, two definition may be associated with the same 
concept only if they belong to different points of view. Violation of this rule means that 
there is a definition conflict. 

In IBIS, there are three types of elements: issues, positions, and arguments. A posi- 
tion can be seen as a way to solve a given issue, and an argument may be in favor or 
against a position. In ConceptIBIS, we use the IBIS model to formalize and keep track 
of the conflict resolution process. Definition conflicts are the issues; a position corre- 
sponds to the choice of an operation in the conflict resolution process (defined in section 
4); and arguments are in favor or against choices. Each operation is related to its oper- 
ands which are objects of the model (definitions, points of view, concepts, etc.). For in- 
stance, the operands of an operation “associate definition d with point of view v” has 
two operands of type Definition and Point of view respectively. Since the concept base 
construction process involves modifying definitions, it is necessary to keep all the ver- 
sions of a definition which have been involved in a conflict resolution operation. Thus 
each definition version is linked to the previous version. Finally, an endorsement is a 
recognition by some authority that a given definition - concept - term association is val- 
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id. Fig. 1. shows a formal definition of the structure of ConceptIBIS (using a UML-like 
notation) 




n to m association aggregation (is made of) 

► n to 1 association 

Fig. 1. The ConceptIBIS model in UML 

The generic association between definitions is a syntactic relationship which means 
that a definition inherits definition elements from another one. The generic association 
between concepts is semantic one, meaning that the generic concept has a wider inter- 
pretation (set of instances). The notion of synonym is implemented by connecting two 
terms to the same concept. 

2.2 Definition Model 

We use the definition model that was developed for the creation of multilingual concept 
bases in the ConcepTerm project [1]. The model we use here is a slight extension of the 
model presented in [1 1]. The extension consists in introducing number constraints as a 
separate construct instead of using “number” characteristics'. 

A definition is a specialization of a more general definition: it is composed of a set 
of characteristics. A characteristic has a name, a quantifier or a number restriction and 
a value definitions. A value definition is itself a definition, it specifies which object cat- 
egories are allowed for a given characteristic. Formally, a concept definition is a state- 
ment which follows the following syntax: 

ConceptDefinition ::= 

definition Definitionid generic Definitionid characteristics Characteristic* 



1 . This extension was dictated by early results we obtained with the comparison algo- 
rithm. It is intended to reduce the relative importance of having equalities on number re- 
strictions when comparing concepts. 
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Characteristic [all | NumberRestriction] CharacteristicName Value 
NumberRestriction "<" PositiveNumber NonNullPositiveNumber ">" 

PositiveNumber "0" | "1" | "2" | ... | 

NonNullPositiveNumber "1" | "2" | ... | 

Value [not] Term | Disjunction | Conjunction | Characteristic 
Disjunction Value* 

Conjunction ::= "(" Value* ")" 

Where * denotes 0, 1 or several occurrences of an element; [] denotes 0 or 1 occur- 
rences and I denotes alternative. 

Example. A definition for the concept [wardrobe] ^ 
definition wardrobe 
generic storage_fumiture 
characteristics 

Dimension : big, 

Part : (type : door) 

Part : <2, *> (type : shelf) 

Part : (type : body) 

all Main_Use : (verb : store, object : {linen ; clothes}) 

Terms which appear in a definition indicate predefined concepts, i.e. concepts for 
which there is not an explicit definition in the concept base (atomic concepts). The ato- 
micity of a concept is not an absolute notion, it is relative to a field. For instance, wood 
can be regarded as atomic within the furniture field whereas it will be explicitly defined 
when talking about building materials. 

It is sometimes useful to view a concept definition as a syntax tree with each arc rep- 
resenting a characteristic. In parficular, we will define the definition comparison oper- 
ation in terms of tree transformation. The following figure shows the tree representation 
of the previous example (wardrobe). 



wardrobe 




1. from the “Furniture” concept base of ConcepTerm project 
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The semantics of a definition is a subset of an interpretation domain. This subset cor- 
responds to the extension a concept. A knowledge base is a set of definitions. An inter- 
pretation I of a knowledge base (KB) is composed of 

• a set (the interpretation domain) 

• for each elementary concept e (designated by a term), an interpretation 
e^cA^ 

• for each characteristic R, a relation c A^ x A^ 

The interpretation of a definition is obtained by applying the following rules : 

I(generic G characteristics Kj K2, . . . KJ = 1(G) n I(K2) n ... n I(K„) 



I(R: <min, max> V) 
I(all R: V) 
I((Ci,C2,...,CJ) 
I({Ci,C2,...,C„}) 
I(temi) 
I(not term) 



= { o I min < card{p e I(V) | (o, p) e R^}< max} 
= { o I V p. (o, p) e R^ => p e I(V) } 

= I(Ci)nI(C 2 )n...nI(C„) 

= I(Ci)uI(C2)u...uI(C„) 

= term', 

= a' \ term'. 



Commutativity and associativity of the union and the intersection imply that the or- 
der in which the elements of a concept definition appear has no importance (interpreta- 
tion remains unchanged under element permutation). 

This model and its semantics are close to the terminological knowledge representa- 
tion model ALCNR [4]. The main difference lies in the number restriction construct. In 
ALCNR a number restriction applies to a role (< n Role and > n Role) while in Concep- 
Term it applies to a role and a value {Role: <min, max>Value), meaning that an instance 
of this concept must be linked to at least min and at most max instances of Value through 
Role. If there are several characteristics with the same name, an equivalent ALCNR def- 
inition can be obtained by introducing new role names. 

In terms of concept base, a definition is represented by objects of the classes and as- 
sociations shown in Fig. 3.. In the ConceptIBIS system, definitions are actually stored 
under this form. 




Characteristic, Conjuction, Disjunction, and Literal are subclasses of Value 
Fig. 3. Structure of a definition in UML-like notation 
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3 Operations for Collaborative Work 

The main operations of the ConceptIBIS model are the definition comparison (to detect 
conflicts), and definition derivations (to help the resolution process.) 

3.1 Definitions Comparison 

Comparison is the basic operation to identify consensus and divergence, identify syn- 
onyms, etc. It is central in a process of collaborative building of concept bases. The 
comparison of two definitions is done by comparing their respective sets of character- 
istics. For this operation to be useful, it must indicate precisely the differences that exist 
between two definitions. A boolean comparison is not enough (A is equal to B or A is 
different from B); neither is a comparison that calculates a distance between two con- 
cepts and only gives a positive real number (whatever the sophistication of the calcula- 
tion). One should also note that the n-dimensional distance is not applicable since 
characteristics may be multivaluated. 

Our approach, which is mostly syntactic consists in expressing the difference be- 
tween two definitions Cl and C2 as modifications. A modification of a definitions Cl, 
regarded as a tree, is a labeled tree which is an extension of Cl. Arcs coming from Cl 
may remain unlabeled (unchanged) or be labeled with [-] to indicate subtree removal. 
Added subtrees are labeled with [+] on their to level arcs. Similarly, number constraints 
may be added and removed. A difference between definitions Cl and C2 is a modifica- 
tion of Cl which, when evaluated, yields C2, and has minimal complexity. 

Cl= C2 = 

generic storage_fumiture generic storage_fumiture 

characteristics characteristics 

Dimension: big Part: <0,*>(type: door, 

Part: <!,*> (type: door), material: (type: pane) ), 

Part: <!,*> (type: shelf), Part: <2,*>(type: shelf) 

Part: <!,*> (type: body) Main_Use: 

Main_Use : <1,1> (verb: store, <1,1> (verb: store, object:books) 

object: {linen; clothes}) 



Fig. 4. Two concept definitions 

Example. Let Cl and C2 be the definitions shown on Fig. 4.. The following expression 
is a modification of Cl that yields C2: 

[+] Dimension: big 

Part: [-]<l,*>[-i-]<0,*>(type: door, [+] material: (type: pane) ), 

Part: [-]<l,*>[-i-]<2, *>(type: shelf), 

[-] Part: <l,*>(type: body) 

Main_Use: (verb: store, object: {[-] linen; [-] clothes; [+] books} ) 

The complexity of a modification depends on the number of modification labels it 
has and the depth at which these labels occur. A modification label at level n has weight 
1/p", where p is an integer parameter greater than 2. 

If a modification is composed of characteristics Kj, ..., Kj^, its complexity %(M) is 
defined as the mean of the characteristics’ complexities: 
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X(M) = (x(Ki) + ...+x(K„))/n 

The complexity of a labeled characteristic is recursively defined by the following 
rules: 

adding/removing a characteristic 

%([ ] R ^in, max> : V) = %([ ] all R : V) = 1 
modification of a number constaint 

X(R : [-\<min, max> [+]<min', max’> V) 

^ ^comp + 1/p %(V) if <min, max> et <min\ max'> are compatible 
^ i’incomp ^ i^P X(^) if max> et <min', max'> are incompatible 

(Constraints are incompatible if the set of integer they define have an empty inter- 
section, bconjp and bi^comp ^re real number parameters satisfying b^omp ^ bincomp 

i^incomp ^ 1/p ^ 1-) 

modification of the values (values may be characteristics, conductions, 
disjunctions, or literals) 

%(R <min, max> : V) = %( all R : V) = 1/p %(V) 
adding or removing a conjunction, a disjunction, or a literal 

x([ ]{Vi, vj) = x([ ]{Vi; V„}) = x([ ]not [-] term [+] term') = 1 

adding or removing an element within a conjunction or a disjunction 
X((Vi,...,V„)) = x(Vi) + ...+x(V„))/n 
X({Vi;...;V„}) = x(Vi)+...+x(V„))/n 

Formal definitions of the notions of modification and difference, as well as a discus- 
sion on the computational and semantic properties of the difference can be found in 
[ 11 ]. 

It is important to note that this notion of difference is essentially syntactic. Flowever, 
when the complexity of a difference is null, we are sure that both definitions have the 
same interpretation, but the converse is not true. In fact, computing a semantic distance 
would require to know the interpretation of each predefined term, which is not the case 
in the bases we consider. As mentioned before, what is most important for conflict res- 
olution is to have a clear view of what makes two definitions different. In addition, we 
are interested in finding syntactic differences even if they have no semantic effect. This 
is typically what happens when two designers have used different characteristic names 
to mean the same thing. Since we consider this situation as a conflict, it must be detected 
when computing differences. 

The complexity of the distance and difference calculation is exponential, because in 
all cases of (and), (or) and multivaluated characteristics (several characteristics with the 
same name), one needs to try all possible permutations to find which one minimizes 
complexity. However, in the real cases that we met, the size of the permutations was 
limited. 
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3.2 Manipulation Operations: Derivation 

Once comparison has been carried out, one needs a few manipulation operations in or- 
der to make further steps towards consensus. Basically, manipulation operations should 
enable the modification of existing definitions. But as endorsements refer to terms and 
definitions, modifying a definition could invalidate an endorsement. Similarly, conflict 
resolution arguments refer to operations and operands and could be invalidated by def- 
inition changes. To avoid this situation, it is forbidden to change definitions that are ref- 
erenced from an endorsement or argument. Every operation must be done either on a 
new version of an existing definition or on a completely new definition (both are basi- 
cally a copy of the original definition). 

In other words, one can say that all manipulation operations are grouped under the 
“derivation” label. A derivation is a new definition which is created from an existing 
definition by either 

• moditying the name and/or the value of one or more of its characteristics, or 

• adding one or several new characteristics, or 

• removing one or several characteristics. 

A derivation can either be considerated as a new version of the original definition or as 
a completely new definition. (A new version of a definition still refers to the same con- 
cept, whereas a new definition corresponds to a new concept.). The following two op- 
erations are intended to automatically produce derivations that can help in the resolution 
process. 

Definitions Interseetion 

The intersection of two definitions A and B is a new definition that possesses only their 
common parts. This operation depends on the difference between A and B that is cho- 
sen. If D is a difference (labeled tree) from A to B, the intersection corresponding to D 
is obtained by removing all the [-] or [+] labeled subtrees that belong to a conjunction 
(including the top-level characteristics); retaining all the subtrees that belong to a dis- 
junction; and removing all the [-] or [-I-] labeled cardinality constraints and universal 
quantifiers. One can see that the intersection creates a definition that is more general 
than the intersected definitions (i.e. its interpretation will always contain the interpreta- 
tion of each intersected definition). 

Definitions Union 

The union is the dual of the intersection operation. It retains all the characteristics of 
both definitions which are in a conjunction and retains only the common characteristics 
in disjunctions. It creates a definition whose interpretation is included in each one of the 
original definition interpretation. 

Although these two operations do not automatically solve definition conflicts, they 
produce different alternatives that can be examined by the designers. This corresponds 
to the well known conflict resolution technique which consists in generating and pro- 
posing new alternatives. 



4 Conflict Analysis and Resolution 

In ConceptIBIS, we use the term “conflicf ’ when: 
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• two (or more) terms designate the same concept, 

• in a given field, two (or more) definitions describe the same concept and they 
belong to the same point of view. 

The first type of conflict can be solved by answering to the question: “Are those two 
terms synonyms?”. In the case of a positive answer, a synonymy link is created between 
them. Otherwise, it is necessary either to remove one term, or to create a new concept 
for one of these terms. Solving definition conflicts will be the main topic of this section. 
We will first situate the conflict resolution task within the terminological knowledge 
base building process. Then we will show what can be done automatically to analyze 
definition conflicts and indicate which operations can be used to resolve them. 

4.1 The Collective Creation Process 

The collaborative building of a terminological concept base with ConceptIBIS is an it- 
erative process. We can see three main phases: 

1) Free creation of terms, definitions and concepts. 

2) Deliberations: participant can show their agreement or disagreement with 
the definitions by creating positive or negative endorsements. 

3) Conflict analysis and resolution 

The conflict analysis and resolution phase can be applied locally to a part of the knowl- 
edge base, while the other parts remain in phase 1 and 2. Moreover, it is not compulsory 
to resolve all the conflicts to return to phase one. The idea is that the knowledge base is 
built progressively and also becomes gradually more consistent. 

4.2 Using Comparisons to Analyze Conflicts 

Testing Generalizations and Specializations 

If there exist a path F from D1 to D2 which only contains [+] in conjunctions and [-] in 
disjunctions and which only restricts cardinality constraints and adds universal quanti- 
flers, then it is sure that the interpretation of D1 will contain the interpretation of D2 
(this is true because there are no negations outside literals and also because the <0,0> 
cardinality constraint is forbidden and replaced by a universal quantifier). One will then 
say that F proves that D2 is a specialization of Dl. If D2 is a specialization of Dl. 

Testing Compatibility 

Dl and D2 are incompatible if no object can fulfil both definitions at the same time. 
With the analysis of differences between Dl and D2 it is possible to prove some cases 
of incompatibility. However, one can not prove every incompatibility case because it 
would require a precise knowledge of concepts corresponding to terms used in literals. 
One can enumerate a set of inference rules which allow to discover some incompatibil- 
ities between definitions, (incoherent concept detection in CLASSIC [2]) 

A difference F between two concepts definitions or between two value definitions 
proves the incompatibility of two definitions in the following cases: 

Replacement of a Literal by its Negation, 

F contains: [+] term [-] not term or [-] term [-t] not term 
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Replacement by an Incompatible Cardinality Constraint 
F contains: R [-] <min, max>[+]<min', max'>: D 

where <min, max> and <min', max'> are incompatible and D only contains operations 
eorresponding to a generalization or a specialization. 

Ineompatibility between an Existential Characteristic and an Universal 
Characteristie 

If one can prove the ineompatibility between D and D’ (by analysing their differences) 
and F contains: [+] all R : D and [-] R : D' (or the opposite). 

Conjunction 

if one can prove that D; and Dj are incompatible and F contains: (Dj, ...,[+] Dj, ..., [-] 

Dj, ...,DJ. 

Disjunction 

if for 1< i < n and 1 < j < m one can prove that Dj is ineompatible with Ej and F eontains : 
{[+]Di; ...; [+]D„; [-]Ej; ...; [-]E^|. 

Compatibility is independent from distance (the complexity of a difference) between 
definitions. For example, if two definitions have no common characteristic, they will be 
perfectly compatible even if the distance is large. The compatibility of two definitions 
does not neeessarily imply that they represent the same coneept. A human intervention 
is required to complete the diagnostic, that is to identify semantic incompatibilities that 
difference analysis can not detect. Compatibility should be regarded as a constraint rule 
that the knowledge base must validate in order to be in a coherent state. For the knowl- 
edge base to be in a eoherent state, two definitions of a same concept, must be compat- 
ible and belong to different points of view. However, during the development of the 
base, incompatibilities are allowed. 

4.3 The Resolution Process 

The coneept base is in a coherent state if, for each concept, there is at most one eurrent 
definition per point of view, and if all these definitions are compatible. When a defini- 
tion confliet oceurs, there are three possibilities to solve it: 

• Consensus: only one definition is kept. For that purpose, one can either re- 
move one of them or merge the two basie definitions, with the union opera- 
tion for example. 

• Contrast: one decides that the two definitions correspond to two different 
concepts. One can then either ereate a new concept and a new term for one 
of the definitions, or create a new concept, keep the same term and link to 
another field. 

• Different points of view: the two definitions are kept but eaeh one is linked 
to a different point of view. 

Remark: We use the terms: “conflicf ’, “consensus”, “correspondence” and “contrast” in 
the same way as Shaw and Gaines [16] (see table in section 1.2) 
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Table 2. D1 is a generalization (specialization) of D2 





Possible operations and typical arguments (arg) 




1 


keep both D1 and D2 + link them to different points of view 
argument: the specific characteristics of D2 are useful for a 
point of view and useless for the other 




or remove one of them + choose a point of view 




same 


argument D1 is incomplete / D2 is hyperspecific (some of 
its characteristics are redundant) 


D1 and D2 
compatible 


concept 


Remark. 

union(Dl,D2)=D2 / intersection(Dl,D2)=Dl so it is useless to 
suggest a merge operation 




2 


create a new concept + create a new term for one of the def- 
inition. + create an inheritance link between D1 and D2. 




different 

concepts 


argument, the characteristics of D2 that are not in D1 make 
the specificity of D2. 



Table 3. D1 is not a generalization (specialization) of D2 





Possible operations and typical 
arguments 


D 1 and D2 
compatible 


3 

same 

concept 


keep both D1 and D2 + link them to different points of view 
or remove one of them 

argument. D1 and D2 are similar 
or create a new definition by combining D 1 and D2, for exam- 
ple by using union(Dl, D2) or intersection(Dl,D2) 
argument, (for union) D1 and D2 are incomplete (not spe- 
cific enough) 

or keep both + create a new definition by combining D1 and 
D2 + link to different points of view 
argument. D1 and D2 are both interesting, but it would also 
be useful to have a more “general” definition 


4 

different 

concept 


create a new concept + create a new term 
or create a new concept + keep the same term + link to another 
field 

argument: D1 and D2 are homonyms 
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Table 3. D1 is not a generalization (speeialization) of D2 







same as 3 




5 


Remarks'. 

union(Dl,D2) is incoherent (empty interpretation) 


D1 and D2 


same 


In this case, keeping both D 1 and D2 and linking them to differ- 


concept 


ent points of view is not a completely satisfying solution, because 
the knowledge base stays in an incoherent state. 


incompati- 

ble 


6 


same as 4 






different 






concept 





We can see that conflicts can be solved using simple operations, for example: create 
a new concept, associate definition to different points of view, “merge” definitions, de- 
lete a definition. The choice of an operation must be justified by an argument. In Table 
2. and Table 3., we enumerate possible operations to apply in each situation, with ex- 
amples of typical arguments Of course, the proposed resolution process does not auto- 
matically lead to an acceptable solution. So, designers may decide to suspend the reso- 
lution of a particular conflict and to wait for some new versions of a conflicting defini- 
tion, as shown in Fig. 5.. 



two definitions for one concept 



C conflict analysis 
and resolution process 

conflict solved 



new version of a conflicting 
definition 




resolution 

suspended 



human decision to suspend resolution process 
(does not find a satisfactory solution) 



Fig. 5. the conflict resolution process 



Keeping Track of the Decisions: Arguments and Endorsements 

Storing the arguments underlying each operation together with terminological knowl- 
edge allows to remember how “final” definitions were chosen, thus avoiding to repeat 
past reflection. Arguments represent informal knowledge (in the sense of Conklin [6]). 
Arguments are informal knowledge that give a background to operations. 

Endorsements act as “checkpoints” in the process. They “mark” situations which are 
approved by some authority. Even if the knowledge base continues to evolve, they form 
references. From an end-user point of view, the most interesting definitions are proba- 
bly not the latest versions but the latest approved versions. 
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5 Conclusion 

In this paper we have presented ConeeptIBIS, a formal concept model which is aimed 
at the collaborative building of terminological knowledge bases. ConeeptIBIS provides 
a multi point of view management support. In addition to its formal part, this model also 
enables to store informal knowledge that gives information on how the terminological 
knowledge is built. 

Then we described a process to resolve the conflicts that inevitably occur when a 
group of people is involved in the building of a concept base. This process includes: 

• semi-automatic conflict analysis with the help of the concept comparison 
operation and its resulting differences 

• operations to resolve conflicts 

• memorization of arguments to justify the choice of an particular resolution 
operation 

• endorsement to express agreement on definitions 

We are currently testing the comparison operation, as well as other operations, on a mul- 
tilingual concept base in the held of furniture. The results obtained so far are encourag- 
ing. 

Meanwhile, we are developing a collaborative system, with a Web interface, for 
translators and terminologists to easily exchange terminological knowledge. This sys- 
tem currently deals with textual definitions. We are now working on the integration of 
this ConeeptIBIS in this system. 
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Abstract We promote a new approach for knowledge modelling based 
on knowledge elicitation from technical documents. It benefits of the 
increasing amount of available electronic texts and of the maturity of 
natural language processing tools. The approach defines a framework 
where the knowledge engineer selects the appropriate tools, combines 
their use and interprets their results to build up a domain model. The 
paper presents the method and reports an on-going application to design 
an ontology of knowledge engineering tools in French. 



1 Introduction 

Ontology design has been a very active field of investigations in knowledge en- 
gineering (KE) over the last 10 years. Recently, studies have focused on either 
reuse as a solution to ontology building, or automatic knowledge acquisition us- 
ing learning techniques and data mining, or integration with problem solving 
models. However many basic problems still remain unsolved [6] [36]. For exam- 
ple, concept definitions, selecting the right properties, defining the semantics of 
relations or even proper grouping of concepts are barely mentioned. In the best 
cases, guidelines propose to organize terms into a taxinomy, to gather synonyms 
into clusters and to define concepts from them [18]. But too little is said on 
which criteria may guide the knowledge engineer during knowledge structuring. 

This leads us to advocate a different method based on linguistics and to give 
a central role to texts. Such an approach takes its roots in the early French works 
of knowledge acquisition with the KOD method and the K-station workbench 
[37]. It was the first attempt to consider texts as main knowledge repositories, 
and approaches in linguistics and terminology as the proper way to explore 
them. About 10 years after, both convergent theoretical problems and sufficient 
maturity led the French KE, AI, Terminology and Linguistics communities to 
cooperate into the TIA (Terminology and Artificial Intelligence) working group. 
TIA group’s major statements are to start from texts to acquire knowledge, to 
connect source texts to conceptual models, to explore texts by applying natural 
language processing tools and techniques based on results in linguistics. 



R. Dieng and O. Corby (Eds.): EKAW 2000, LNAI 1937, pp. 172-188, 2000. 
© Springer- Verlag Berlin Heidelberg 2000 




Revisiting Ontology Design: A Method Based on Corpus Analysis 173 



Several states of the art in ontology design show that texts are hardly used 
or, at least, they aren’t explicitly mentionned as knowledge sources. When used, 
texts are read and manually explored without any precise indication of the ap- 
plied techniques. In fact, knowledge reuse is much preferred and studied as an 
acute problem, often to the detriment of the ontology actual usability in the cur- 
rent application [26], [6]. The relation between ontologies and texts gains interest 
with the development of the Internet and with the generalisation of electronic 
documents. Ontologies look like a promising ressource to improve information 
retrieval in documents, to index them [35] or to make them easily available 
among a community of readers [14]. Ontologies and texts may be connected in 
two ways: either concepts are used as semantic tags added to documents, or texts 
are connected to some concept instances in the ontology. Even in these cases, 
the documents themselves are not used as input of the modelling. 

In this article, we present our method for domain knowledge elicitation and 
modelling from texts. First, we describe the approach characteristics with regard 
to other trends in knowledge acquisition from texts. We go on with a review of 
the approach, its main stages and their intermediary outputs. To end with, we 
report the early stage of an experiment where we applied it to organize the 
concepts describing KE tools in France from French documents. 



2 Recent Trends in Knowledge Acquisition from Texts 

2.1 Classical KA from Texts 

Since the early 80’s, researchers in knowledge acquisition (KA) are interested in 
text analysis to make acquisition easier. Two major trends, presented in [7], were 
tools for the automatic translation of texts into a knowledge base and hypertext 
editors. This classification remains valid today. 



Automatic transfer tools. Based on linguistics, they usually combine a text 
parser with a knowledge analyser that tries to represent knowledge into a for- 
mal linguistic language. This representation is then translated into logics in the 
knowledge base. The knowledge analyser may also be a classifier or an inductive 
generalizer [28]. Most of these systems have the ambitious goal to extract any 
kind of knowledge from natural language texts, whereas some specialize on spe- 
cific knowledge (such as taxonomic knowledge [17] or causal knowledge). Most 
of them refer to general relation types and ontological classes to start the pro- 
cess and to organise concepts. They set high expectations on the performance of 
the parser, whereas it is doubtful to get an efficient parser for any natural lan- 
guage. We agree with Bourigault’s severe evaluation of these tools: they carry 
out costly, hazardous and, worst, often useless analyses. Other automatic tran- 
fer tools learn concepts from a statistical clustering of terms (like co-occurring 
terms) that should identify concept classes. These systems cannot give informa- 
tion to help to judge the quality of their analyses [20] . 
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Automatic transfer tools still form part of a language understanding chain. Im- 
provements in text parsers by enriching the semantic analysers (for instance with 
recent results about verb constructions) turned SNOWY-BIOS, a new version of 
SNOWY, into a powerful tool to answer questions about biographical texts [22]. 
Hahn’s view relies on the same basic goal to automate text understanding as 
a prerequisite for KA. Automation in his system [20] is a two-step process: the 
parser generates concept hypotheses, that are later on evaluated by a qualifier. 
This qualifier is a set of quality evaluation meta-rules, which contain general lin- 
guistic knowledge. The meta-reasonner classifies the various hypotheses which 
guides the KE to decide to which class add an instance in the concept hierarchy. 
The rules can be tuned in keeping with the application, which makes the tool 
more powerful. It must be underlined that automatic transfer tools are rarely 
used outside their development team, which points out their immaturity. 



Hypertext systems. They guide text exploration and analysis, and include 
text browsers and devices to connect conceptual structures to natural language 
phrases underlined in texts. In the most powerful systems, the text decomposi- 
tion into units (sentences, paragraphs or word lists) is model driven [30] . Hyper- 
text capabilities to browse expertise documents such as transcripts of interviews 
are still a basic device in KA plat-forms. PC-PACK, the knowledge elicitation 
tool of the CommonKads method [31], includes such functionnalities. 



2.2 A New Proposal 

A new trend appeared recently, born from a major evolution of Terminology. 
It mixes up acquisition tools based on linguistics with browsing and modelling 
tools keeping links between models and texts. This evolution is due to new 
Natural Language Processing (NLP) tools which are corpus oriented and have 
gained efficiency from valuable collaborations between linguists, terminologists 
and knowledge engineers. This trend is less ambitious that the automatic trans- 
fert approach: NLP tools are seen as helps for the knowledge engineer who selects 
and combines their results to build up the model. Moreover these linguistic tools 
are of a different kind. Instead of general language understanding parsers, they 
deliver specific kinds of linguistic ressources. They are all the more efficient as 
they can be adapted to each application. 

Exploring corpora to identify thesauri, terminologies or even ontologies re- 
quire to define new methods and techniques [3], which rely on a novating theo- 
retical framework in Linguistics [34]. This linguistic theory is an interpretative, 
linguistic and textual semantics: its object is the attested text, the meanings are 
described through linguistic paraphrases, and the interpretation provides the 
meanings. Moreover, a concept is a normalized meaning, which results from a 
work of restriction with respect to the corpus and the application. The method 
follows some precise steps: a corpus is set up, then terms and lexical relations 
of the domain can be extracted automatically. The designer builds concepts 
and semantic relations from studying the use of the corresponding words in the 
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texts. The target conceptual model is more than an intermediate data, it is a 
result in itself. It can be used later as a knowledge source, for instance to de- 
fine indexes, glossaries or thesauri. Conceptual models usually set apart static 
domain knowledge from problem solving knowledge. Depending on the type of 
text, a text analysis can bear on any of them. For instance, procedure guidelines 
are relevant to acquire reasoning knowledge. Until now, only domain knowledge 
(concept descriptions and their organization) is considered. 

The method we propose in this trend emphasizes the purpose of the final 
model. Right from the start of the elicitation process, the task is one of the 
filtering criteria to look for knowledge in texts, select it and set it in the model. 
This model is later translated into a formal concept description in a terminolog- 
ical logics so that its consistency and validity could be automatically checked. 
Moreover, our method fulfills basic engineering principles and suggests to start 
any project by a precise study of the needs to be met by the model. In the 
following, the domain is bound to the task, the selected corpus and domain 
specialists. Our proposal promotes to study the domain after breaking it into 
sub-domains. It classically suggests to reuse existing resources such as model or 
domain ontologies, terminologies, thesauri or indexes and so on. 

In the next section, we present the main stages of our method. 

3 Methodological Framework 

This method is general, and independent of the language used in texts. It de- 
fines a framework where some technical and methodological choices are left to 
the knowledge engineer, depending on different factors: the application require- 
ments; available technical documents; elements of existing models (ontologies, 
terminological ressources like thesauri or glossaries); human expertise; available 
NLP tools (which depend on the language used in texts. 

The designer who follows the method is more or less qualified in linguistics, 
in knowledge modelling and in formalization. At every step, he/she must decide 
which techniques must be used depending on the previous factors and his/her 
own ability. To use the method, he/she needs a specific software to manage a 
great amount of information (terms, concepts and relations), to describe it, to 
organize it and to formally represent it. Such an environment must allow an 
easy access to the terms and the lexical relations, the texts from which they are 
extracted and the model in which they will be inserted. 

We have already developed Terminae [5] and Gediterm [2] for this purpose. 
Terminae offers to consult a corpus and to integrate the results of the Lexter 
extractor of term-candidates ^ . The designer extracts terms from the list of term- 
candidates and defines notions from term meanings. In Terminae, a notion refers 
to a concept under modelling, whereas a concept is formal. These notions are then 
structured and differentiated, to be finally formalized as concepts (keeping the 
link to the corpus). In Terminae, the formal language is close to terminological 

^ A term-candidate is a syntagm extracted from texts that may become a term if 
validated by an expert. 
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logics. The link is kept between each formal concept, the notion, its associated 
terms and their occurrences in the corpus. Gediterm assists the first steps to 
select terms. The term/concept link is justified by the occurrences of the terms 
in the corpus. Terminae and Gediterm both may take as input the list of term- 
candidates given by Lexter. Gediterm does not allow the resulting conceptual 
network to be formalized but it provides tools for a better management and 
visualization of the conceptual network before its formalization. 

In what follows the methodological framework is presented, focusing firstly on 
the nature of the data used and produced during the process, from the corpus 
to a domain model. Then the main stages of the process itself are described. 



3.1 From Texts to a Formal Model 

The method applies on technical documents and ends to a formal domain model. 
It differentiates terms from concepts, and lexical relations from semantic rela- 
tions. Terms and lexical relations are syntagms occurring in the corpus and 
regarded as important in the domain. Lexical clustering puts together syntagms 
which occur in some similar contexts. The syntagms are interpreted in a local 
context (sentence or paragraph) then in a global one (text or whole corpus). 
If they are considered as terms, they give rise to concepts and semantic rela- 
tions that they label. The set of concepts and relations makes up a semantic 
network, informal but understandable by the designer. Then concepts and re- 
lations are formalized into a terminological language close to description logics: 
concepts and roles are structured into an inheritance hierarchy. The concepts 
are characterized following two dimensions, a linguistic one to express how close 
to a syntagm in the corpus a concept is, and a pragmatic one, reflecting the 
reasons why the concept has been integrated into the formal model. This infor- 
mation makes both the model and the knowledge base easier to understand and 
to maintain [4]. 



3.2 Used Natural Language Processing Tools 

We have selected the most frequently used tools in the French TIA commu- 
nity. We differentiate tools dedicated to terminological knowledge acquisition 
(TKA) from texts, and particularly terminological extractors, from classic lin- 
guistic tools for NLP. 



Terminological extractors. Term-candidate extractors extract from a corpus 
a list of terms that must be validated. They return a great amount of data often 
with some noise; so a long and boring selection must be made that requires both 
a good domain expertise and a good anticipation of the way terms will be used. 
These tools can be based on syntactic principles, as Lexter [8] and Nomino [13], 
or on statistic principles as Ana [15] and Startex [29]. Their use does not imply 
a great competence in linguistics. 
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Relation extractors are usually based on linguistic patterns such as Promethee 
[25] or Cameleon [32] . Some of these tools need first to be provided with general 
linguistic relation patterns like ”x is indefinite_ARTICLE y” for the hyper- 
onymy relation (kindOf). Patterns are applied on the corpus in order to visu- 
alize the pieces of texts where the lexical relation appears. Other tools require 
couples of related forms as input, from which specific patterns are identified. 
Starting from some predefined patterns their application onto the corpus rises 
up terms from which domain specific patterns may be created for new lexical re- 
lations. The use of these tools requires some linguistic skills but gives significant 
information for structuring the domain. 

Term and relation extractors may be used in a separate or complementary 
way. If a term extractor is firstly used, then relations between terms may be 
searched for by exploring their contexts. If a relation extractor is firstly used, 
then projecting the relations onto the corpus may rise up related terms. These 
tools usually offer an environment to browse their results. 



Other terminological tools. Some TKA tools are more oriented towards 
concept discovery. Conceptual clustering tools like Zellig [19] or Lexiclass [1] put 
together noun phrases that share syntactic dependency relations. The resulting 
clusters must be manually analyzed to define semantic classes. Results interpre- 
tation is difficult but term structuring and concept definition is made easier. 
Asium [16] uses learning techniques to propose term clusters. Each cluster must 
be manually validated before defining concepts. Synoterm [21] offers potentially 
synonym clusters, that can be also considered as concept-candidates. Lexis [27] 
finds names in a corpus, which may be useful to find some class instances. 

An example of sophisticated acquisition tool working in English is KAWB 
(Knowledge Acquisition WorkBench) [24]. It acquires some semantic classes of 
a domain from large text corpora. It uses various methods from computational 
linguistics, information retrieval and KE. A data extraction module includes 
word class identification based on linguistic annotation of texts, statistical word 
clustering, with access to external linguistic and semantic sources. A pattern 
finder collects word collocations, searches for regularities and proposes lexico- 
semantic patterns for a conceptual characterization to the user. An analysis 
and refinement module helps the user to test patterns which represent his/her 
hypotheses, groups together the cases and generalizes them to ask the user for 
a final decision. 



Classic linguistic tools. Some simple and very easy to use linguistic tools 
have been available for many years now, like concordancers and KWIC tools. 
KWIC (KeyWord In Context) tools bring into vertical alignment along a given 
word or phrase all the sentences of a corpus in which this word occurs. This 
is very practical to study all its contexts, its linguistic behaviour and, first of 
all, to get an idea of its meaning from the way it is used. Concordancers offer a 
similar assistance: they look into the corpus for every occurrence of any user given 
syntagm. They are more powerful than KWIC tools because these syntagms may 
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be characterized by syntactic or semantic properties, not only by giving explicit 
nouns phrases or verbs. So concordancers result very practical to apply and test 
some patterns on a corpus, study their occurring contexts and compare them. 

Generic tools for text analysis, such as Sato [12] offer a variety of options, 
which range from research of occurrences and text alignment to syntactic analysis 
and corpus tagging, including statistics on word frequency, disambiguation at a 
syntactic or sometimes semantic level. They may be useful for extracting and 
structuring knowledge when looking for very specific information. 



3.3 Detailed Description of the Method Steps 

The modelling process is detailed below from setting up the corpus along to 
designing the formal model. 




Figure 1. Steps of the modelling process from text according to our approach 



Setting up the corpus. From the requirements that explain the objectives 
underlying the model development, the designer selects texts among the avail- 
able technical documentation. He must be an expert about texts in this domain 
to characterize their type and their content. The corpus has to cover the entire 
domain specified by the application. A glossary, if it exists, is useful to deter- 
mine sub-domains and to verify that they are well covered. The corpus is then 
digitalized if it was not. Beginning the modelling may lead to reconsider the 
corpus. 
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Linguistic analysis. This step consists in selecting adequate linguistic tools 
and techniques and in applying them to the text. Their results are sifted and a 
first linguistic based elicitation is made. The objective is to allow the selection 
of the terms and lexical relations that will be modelled. The results of this stage 
are quite raw and will be further refined. 



Normalization. Normalization is a particular conceptualization process based 
on corpus analysis, in line with [10] in contrast with expert introspection. The 
expertise and the target system influence concept definitions in a second time. 
Indeed, the restricted meaning of concepts is mainly derived from the study of 
term occurrences in texts. These terms become concept labels. Thus concepts 
are described thanks to the use of their label together with the other terms in 
the corpus. So, the corpus plays an important role during normalization. Lin- 
guistic study and normalization are closely intertwined and cyclic activities. At 
any time of the normalization process, we use linguistic tools and principles to 
explore the text and to decide whether a concept, an attribute or a relation 
should be defined or not. 

Normalization includes two parts: the first one is still linguistic, it refines the 
previous lexical results; the second one concerns the semantic interpretation to 
structure concepts and semantic relations. The modelling goes from terminolog- 
ical analysis to conceptual analysis, that means from term to concepts and from 
lexical relations to semantic ones. During normalization, the amount of data to 
be studied is gradually restricted. 

During the linguistic step, among the set of terms and lexical relations, the 
designer has to choose those that will be modelled. This choice is mainly sub- 
jective, the terms and relations are kept when they seem important both in 
the domain and for the application. Because of this subjectivity the selection is 
rather large. Then, from the study of each syntagm occurrences, the designer 
writes in natural language a definition that remains close to the texts. In the 
same time, he determines for each term and relation if it has one or several mean- 
ings in the domain. In case of polysemy, he decides which meanings attested by 
the corpus have to be kept because they are relevant. 

The second step is conceptual modelling. Concepts and semantic relations 
are defined in a normalized form using the labels of the concepts and relations 
already defined. These definitions may be less close to the text as long as they 
must be relevant for the task for which the model is built. These descriptions are 
structured into a semantic network, with a strong emphasis on the hierarchical 
relations (kindOf, partOf). Only the rigor of the work and perhaps the modelling 
environment may guarantee the coherence of this semi-formal ontology. 



Formalization. The formalization step includes building and validating the 
ontology. Some existing ontologies may help to build the highest levels and to 
structure it into large sub-domains. Then semantic concepts and relations are 
translated into formal concepts and roles and inserted in the ontology. This may 
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imply to restructure the ontology or to define additional concepts, so that the 
inheritance constraints on the subsumption links are correct. Inserting a new 
concept triggers a local verification to guarantee the syntactic correctness of the 
added description. A global validation of the formal model is performed once the 
ontology reaches a quite stable state to verify its coherence. 

4 Applying This Method to Describe KE Tools 

To test our tools and refine our approach, we applied it to build an ontology 
of KE tools from a corpus of selected texts in French. For the time being, our 
study is restricted to the tools currently used and developed in France for KE. 
We present the context of the experiment in the section below. Then, we detail 
how we manage the linguistic study and the normalization steps. As long as these 
tasks are performed in a cyclic way, we differenciate the early sifting of the row 
results provided by the linguistic tools from further concept identification and 
clustering, where linguistic tools are used for specific goals. We finally present 
our preliminary results. 



4.1 Context of the Experiment 

Final application. The ontology aims to help researchers in KE to compare 
and describe their own tools with respect to existing ones. Before developing a 
new tool, one may want to know which ones exist with similar functionalities. 



The expertise. The model designers are not linguists but they are specialists 
in KE. As such, they alternatively behave as knowledge engineers or as experts. 



The corpus. We use a corpus built up by the French TIA group for creating 
a thesaurus to index Web pages and documents in KE. The kernel of this cor- 
pus, described in [9], consists of 34 selected papers published in the KE French 
conferences during the last 3 years and gathered in a synthesis book [11]. The 
first term studies showed that the corpus did not cover the whole domain. More- 
over, it contained too few definitions of domain concepts. In order to cope with 
these limitations, it has been enriched with 4 general papers presenting KE. The 
corpus volume raised by 30%, reaching now 207.000 words. 



NLP tools. We use two linguistic tools, a term extractor (Lexter [8]) and a 
relation extractor (Cameleon [33]), and a modelling tool (Terminae). Terminae 
provides convenient modules to validate and to display results from Lexter, as 
well as to organize the terms and to build an informal ontology. We use the 
Terminae concept structure as if it were informal. Each concept is documented 
by a comment. A classifier checks the validity of the insertion of a concept and 
gives warnings to the designer if some mistakes or redundancies are found. As 
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previously said, concepts are characterized along a linguistic dimension. Termi- 
nological concepts are built from the corpus study, and they correspond to one 
or several domain terms, one of them being the concept label. These concepts 
are linked to their term occurrences in the corpus. Pre-terminological concepts 
correspond to several phrases, sometimes as large as sentences, none of them 
being more frequently used than the others. Their label is not in the corpus. 
Non-terminological concepts do not correspond to any term or phrase in the 
domain. It also happens that a concept is needed to structure the ontology and 
that a domain term corresponds to it, but this term is not attested in the corpus. 
In such a case the concept will be defined as terminological but not attested. 

4.2 Linguistic Study 

The early sifting work consists in exploring the row data provided by the linguis- 
tic tools from the corpus analysis. These lists of term and relation hypotheses 
help to quickly read the corpus according to the major domain concepts. 

We could start this work in two different ways: (a) focus on terms and then 
look for relations between these terms or (b) identify lexical relations that help 
to select domain terms. We choose the first way because the aim is to build an 
ontology on KE tools: 

Term study We have two methods to approach corpus analysis, according 
to the weight given to names. Firstly, compound term-candidates including the 
word ’’outil” (tool) indicate potential sub-classes of the corresponding concept 
OUTIL. Lexter extracts 26 349 term-candidates, but only 109 of them begin with 
the word ’’outil”. Secondly the names of specific tools are easily collectable and 
directly identifiable when written in capitals. 

Relation identification Many relations could be easily identified by reading 
term occurrences. However, this practice is as costly and time consuming as 
reading the whole corpus. The number of occurrences to be read is restricted 
by using Cameleon [32]. Cameleon suggests hypotheses of partOf and kindOf 
relations between domain terms. It finds them by applying general linguistic 
patterns that are stored in the system. For this project, we define only two 
new patterns for the kindOf relation like {X is a Y which), which are small 
variations of general patterns. For each concept in the model, we browse the 
Cameleon hypotheses and read their occurrences. Cameleon found about 2 to 10 
relations for concepts under outil, and about 50 relations for outil, the third 
of which have been validated. 

4.3 Normalization 

After sifting through the results of linguistic tools, we have in hand a first list 
of terms. From this list, we have to model concepts and to structure them. 
Each occurrence of each term is closely studied. We decide to suppress terms 
when not suitable for the application, such as ’’outil de bureautique” {office 
automation tool). We also associate various terms to the same notion either 
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because they are judged synonyms in the corpus, or because they are not worth 
being distinguished for the application. We are able to evaluate term synonymies 
because we know the application domain. If it were not the case, we would rely 
on linguistic criteria, like similar uses of these terms in different occurrences. 

Conceptual clustering consists in bringing terms together to form a concept, 
and in defining synonyms. By exploring and comparing all the occurrences of 
some terms, synonymy relations may be observed. Another way to find synonyms 
is to explore the syntactic relations that bind co-occuring terms. 



Examples of synonymy detection by exploring occnrrences. 

— From reading the occurrences of the terms ’’outil textuel” {textual tool), 
’’outil d’analyse de textes” {text analysis tool), ’’outil linguistique” {linguis- 
tic tool), ’’outil d’analyse de corpus” {corpus analysis tool), we decide to 
group these terms under a single concept ’’outil d’analyse de corpus” {cor- 
pus analysis tool) (Figure 2). 

— The term ’’outil anthropotechnique” {anthropotechnical tool) will be rejected 
because it is used with the meaning of ’’outil de genie cognitif’ {knowledge 
enginering tool) and it is not worth being distinguished for this application. 



Synonymy detection thanks to co-occurrences. For each couple of terms 
which we know as experts that they label related concepts, we look for their co- 
occurrences within a window of one sentence using a Terminae module. Several 
criteria guide us to structure the concepts, as illustrated in the following: 

— The terms ’’outil” and ’’methode” {method) are often bound by the coordi- 
nating conjunction and, from which we consider they are not synonyms. An- 
other relation between ’’outil” and ’’methode” is the relation ’’utilise” ( ms es): 
a method ’’utilise” a tool or a tool ’’utilise” a method. There are as many 
sentences of both types, which stresses the ambiguity of the relation label 
’’utilise”. Two relations types with different labels are distinguished. 

— There is no co-occurrence of ” outil” and ” algorithme” , only one of ” outil” 
and ’’formalisme” in which a formalism is defined as a conceptual tool. 

— The 25 co-occurrences of ’’outil” and ’’systeme” put forward two kinds of 
relations: identity(t/ie SATO system is a top-down tool) and inclusion {tools 
of the information system). Inclusion may occur in the two directions (a 
tool includes a specific system or a system consists of several tools), which 
confirms the terms synonymy. 



4.4 First Results of the Structuration 

Our work is at its very beginning, only the kindOf relation has been deeply 
studied. We have to investigate other relations like partOf, ”sert-a” {to be useful 
for), ’’utilise” {uses) or ’’auteur” {author) to continue the structuration. 
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Figure 2. First stage of the normalization of a concept: corpus analysis tool 



As long as we focus on KE tools, we first define the concept OUTIL. Several 
semantic relations such as author, corresponding to lexical relations, describe 
this concept. We organize most of the concepts around OUTIL. From the relations 
presented in 4.3, we distinguish conceptual tools (method, formalism, algorithm, 
model) from software tools. From our expertise and after reading occurrences of 
specific tools, we decide to differenciate two kinds of software tools: results of an 
engineering process and software for system development, which can be either 
KE tools (ouTiL d’ingenierie des CONNAISSANCES) or software engineering 
tools (OUTIL DE GENIE LOGICIEL). 

Thus we create under OUTIL two terminological concepts: OUTIlLogiciel 
{software tool) and OUTIlConceptuel {conceptual tool). Figure 3 ^ shows the 
hierarchy under OUTIL, the next lower concepts {software tool and conceptual 
tool), and the lower levels. 

Only outilIngenierieConnaissances and outil Validation are termi- 
nological not attested (TNA) concepts (c.f. 4.1). The terminological concept 
OUTIlAide gathers all the concepts corresponding to terms which begin with 

^ In the figures showing parts of the ontology, terminological concepts are in italic, 
individual concepts which correspond to a specific tool have a capital first letter. 
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Figure 3. Hierarchy under OUTIL 



9 outilAnalyseCorpus 
9 concordanciet 
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ouiUA naSyseSyntaxique 
Mantex 

9 outirrermmologique 

9 outilExtractionTermesCandidats 
Lexter 
Ana 
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Cameleon 
Promethee 
Seek 
Ikarus 
Syclade 
Startex 



loutilRegroupementConceptuell 



Zellig 

Figure 4. Hierarchy under OUTIlAnal- 
yseCorpus 



’’outil d’aide” {front-end tool). We identify linguistic tools, a particular kind 
of software tools, described in the corpus. Figure 4 presents the concepts un- 
der outilAnalyseCorpus. We define outilExtractionTermesCandidats 
{term- candidate extractor) and outilReperageRelations {relation locating 
tool) as subclasses of outilTerminologique. 



4.5 Experiment Report and Evaluation 

We have focused on knowledge extraction from texts. But we actually take into 
account other knowledge ressources, domain expertise, additional information as 
existing ontologies, databases,... Several criteria guide data selection among these 
various sources: the expertise in the domain and the target application and users. 
These criteria may be contradictory. Priority is given to the relevance for the 
application and to the expertise, which may bias what the text says. For instance, 
ASTREE, a specific tool, is described in a text as a KE tool, which is not precise 
enough in an ontology that should help to compare and characterize KE tools. If 
we read further this text, we understand that ASTREE is a tool that assists the 
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design of a conceptual model. So we decide to define outilAidemodelisation 
as a concept and ASTREE as one of its son concepts. 

To validate our model, we plan to try to add new tools and evaluate whether 
it is easy or not to describe them in the ontology. These tools wil be described 
by a small text in a demonstration form-sheet. We will consider our ontology as 
valid if we can set these new specific tools as concept instances in the ontology. 
This means that either we’ll be able to characterise them conveniently with 
existing properties, or it will be easy to distinguish new sub-classes by taking 
into account new concept properties. The second case will lead to re-organize 
part of the taxinomy in the model. 



5 Conclusion 

In this article we have presented a method to create a domain model from a cor- 
pus analysis, by using NLP tools. We also have reported an experiment where 
we applied it to build an ontology of the French tools of the KE domain. In the 
future this work may be compared to the European project (KA)^ and to the 
team project of [23]. It is also close to the EuroKnowledge project [36] which 
describes the English terminology about ’’modelling at the knowledge level” for 
a didactic book to be used as a reference. 

To experiment our method on an application shows up all its capacities but 
also all the pratical, methodological and even theoretical queries left to be an- 
swered. It is obvious that we have not yet exploited the whole complementarity 
of the different types of analyses that can be made on the corpus. For instance, 
term and relation studies are still used in different environments. We have not 
used all the tools which exist today, especially because they are research tools 
and neither easily available nor usable. But the results obtained thanks to our 
approach are still of a good quality and promising. They have to be completed 
and evaluated in the next step of the project. Additional investigations are also 
needed to extend the approach to other languages than French. 

A list of criteria of effectiveness is presented in the CommonKADS book [31]. 
For each one of them, we are convinced that KA from texts as we presented it 
is a good way to go one step further. Unlike the authors of the CommonKADS 
book, we assert that the previously presented techniques will minimize the effort 
spent in gathering, transcribing, and analyzing the knowledge required by the 
target application. Exploring texts minimizes the time spent with expensive and 
scarce domain experts. The direct connection between texts and models is a 
means to maximize the yield of usable knowledge. NLP tools and linguistics 
based techniques tend to make elicitation techniques a systematic process. We 
assume that these techniques are reliable and mature enough to make the process 
more robust as a whole. For instance, each choice must be justified and many 
references towards texts form a track that improve the model readability. The 
experiment reported in this paper is currently being carried on and we hope the 
final results will give precise measures of the method effectiveness. 




186 



N. Aussenac-Gilles, B. Biebow, and S. Szulman 



References 

1. H. Assadi. Construction of a regional ontology from text and its use within a 
documentary system. In N. Guarino, editor, Proc. of the 1st International Con- 
ferenee on Formal Ontology and Information System (FOIS’98)), pages 236-249. 
lOS Press, 1998. 

2. N. Aussenac-Gilles. Gediterm, un logiciel de gestion de bases de connaissances 
terminologiques. Terminologies Nouvelles, 19:111-123, 1999. 

3. N. Aussenac-Gilles, D. Bourigault, A. Condamines, and C. Gros. How can knowl- 
edge acquisition benefit from terminology ? In Proc. of the 9th Knowledge Acqui- 
sition for Knowledge Based Systems Workshop (Banff ’95), 1995. 

4. B. Biebow and S. Szulman. Terminae : A linguistics-based tool for building of a 
domain ontology. In D. Fensel and R. Studer, editors, Proc. of the 11th European 
Workshop (EKAW’99), LNAI 1621, pages 49-66. Springer- Verlag, 1999. 

5. B. Biebow and S. Szulman. Terminae: une approche terminologique pour la con- 
struction d’ontologies du domaine a partir de textes. In Proc. of Reconnaissance 
des Formes et Intelligenee Artificielle (RFIA’2000), volume II, pages 81-90, 2000. 

6. M. Blazquez, M. Fernandez, J.M. Garcia-Pinar, and A. Gomez-Perez. Building 
ontologies at the knowledge level using the ontology design environment. In Proe. 
of the 11th Knowledge Acquisition Workshop (KAW’98), Banff, Canada, 1998. 

7. D. Bourigault. Lexter, un Logiciel d’EXtraction de TERminologie, Application a 
Tacquisition des connaissances a, partir de textes. PhD thesis, Ecole des Hautes 
Etudes en Sciences Sociales, Paris, France, 1994. 

8. D. Bourigault. Lexter, a natural language processing tool for terminology extrac- 
tion. In Proc. of the 7th EURALEX International Congress, Goteborg, 1996. 

9. D. Bourigault and J. Charlet. Construction d’un index thematique de I’ingenierie 
des connaissances. In Proc. of Ingenierie des Connaissances (IC’99), pages 107- 
118, Paris, 1999. 

10. J. Charlet and B. Bachimont. De Tacquisition a Tingenierie des connaissances: 
Applications et perspectives. In Actes des Assises Nationales 1998 du PRC-13, 
http://www.irit.fr/ACTIVITES/EQ_SMI/GRACQ/index-commf.html, 1998. 

11. J. Charlet, M. Zacklad, G. Kassel, and D. Bourigault, editors. Ingenierie des 
Connaissances, evolutions recentes et nouveaux defis. Eyrolles, 2000. 

12. F. Daoust. Systeme d’ Analyse de Textes par Ordinateur. Centre ATO, Universite 
du Quebec a Montreal, 1992. 

13. S. David and P. Plante. Termino version 1.0. Centre d’Analyse de Textes par 
Ordinateur, Universite du Quebec a Montreal, 1990. 

14. J. Domingue and E. Motta. A knowledge- based news server supporting ontology- 
driven story enrichment and knowledge retrivial. In D. Fensel and R. Studer, 
editors, Proc. of the 11th European Workshop (EKAW’99), LNAI 1621, pages 103- 
120. Springer- Verlag, 1999. 

15. C. Enguehard and L. Pantera. Automatic natural acquisition of terminology. .Jour- 
nal of Quantitative Linguistics, 2/1:27-32, 1995. 

16. D. Faure and C. Nedellec. Knowledge acquisition of predicate argument structures 
from technical texts using machine learning: The system ASIUM. In D. Fensel 
and R. Studer, editors, Proc. of the 11th European Workshop (EKAW’99), LNAI 
1621, pages 329-334. Springer- Verlag, 1999. 

17. F. Gomez. Acquiring knowledge about the habitats of animals from encyclopedic 
texts. In Proc. of the Workshop on Knowledge Acquisition for Knowledge-Based 
Systems (KAW’95), volume 1, pages 6.1-6.22, 1995. 




Revisiting Ontology Design: A Method Based on Corpus Analysis 187 



18. A. Gomez-Perez. Knowledge sharing and reuse. Hand-book of Expert Systems - 
CRC, 1997. 

19. B. Habert, E. Naulleau, and A. Nazarenko. Symbolic word clustering formedium- 
size corpora. In Proc. of the 16th International Conference on Computational 
Linguistics (COLING’96), pages 490-495, Copenhagen, 1996. 

20. U. Hahn, M. Klenner, and K. Schnattinger. Automated knowledge acquisition 
meets metareasoning: Incremental quality assessment of concept hypotheses dur- 
ing texts understanding. In Proc. of the Workshop on Knowledge Acquisition for 
Knowledge-Based Systems (KAW’98), 1998. 

21. T. Hamon, A. Nazareko, and C. Gros. A step towards the detection of semantic 
variants of terms in technical documents. In Proc. of the 36th Annual Meeting 
of the Association for Computational Linguistics and 17th International Confer- 
ence on Computational Linguistics (COLING-ACL’98)), pages 498-504. Morgan 
Kaufmann, 1998. 

22. R. Hull and F. Gomez. Automatic acquistion of historical knowledge from ency- 
clopedic texts. In Proc. of the Workshop on Knowledge Acquisition for Knowledge- 
Based Systems (KAW’98), 1998. 

23. G. Kassel, M.-H. Abel, C. Barry, P. Boulitreau, C. Irastorza, and S. Perpette. 
Gonstruction et exploitation d’une ontologie pour la gestion des connaissances 
d’une equipe de recherche. In Proc. of Ingenierie des Connaissances (IC’2000), 
pages 251-259, Toulouse, 2000. 

24. A. Mikheev and S. Finch. A workbench for acquisition of ontological knowl- 
edge from natural language. In Proc. of the 9th Banff Knowledge Acquisition 
for Knowledge-Based Systems Workshop (KAW’95), 1995. 

25. E. Morin. Acquisition de patrons lexico-syntaxiques caracteristiques d’une relation 
semantique. TAL (Traitement Automatique des Langues), 40/1:143-166, 1999. 

26. N. Fredman Noy and G. Hafner. The state of the art in ontology design : a survey 
and comparative review. Artificial Intelligence Magazine, pages 53-74, 1997. 

27. T. Poibeau. Reperage des entites nommees : un enjeu pour les systeme de veille. 
Terminologies Nouvelles, 19:43-51, 1999. 

28. U. Reimer. Automatic knowledge acquisition from texts: Learning terminologi- 
cal knowledge via text understanding and inductive generalization. In Proc. of 
the Workshop on Knowledge Acquisition for Knowledge-Based Systems (KAW’90), 
pages 27.1-27.16, 1990. 

29. F. Rousselot, P. Frath, and R. Oueslati. Extracting concepts and relations from 
corpora. In Proc. of the 12th European Conference on Artificial Intelligence 
(ECAP96), 1996. 

30. G. Schmidt and F. Schmalhofer. Case-oriented knowledge acquisition from texts. 
In B. Wielinga, J. Boose, B. Gaines, G. Schreiber, and M. Van Someren, editors, 
Proc. of the fth European Workshop (EKAW’90). lOS Press, 1990. 

31. G. Schreiber, H. Akkermans, A. Anjewierden, R. de Hoog, N. Shadbolt, W. Van 
de Velde, and B. Wielinga, editors. Knowledge Engineering and Management: The 
CommonKADS Methodology. MIT Press, 1999. 

32. P. Seguela. Adaptation semi-automatique d’une base de marqueurs de relations 
semantiques sur des corpus specialises. Terminologies Nouvelles, 19:52-60, 1999. 

33. P. Seguela and N. Aussenac. Extraction de relations semantiques entre termes et 
enrichissement de modeles du domaine. In Proc. of Ingenierie des Connaissances 
(IC’99), pages 79-88, Paris, 1999. 

34. M. Slodzian. Comment revisiter la doctrine terminologique aujourd’hui? La Banque 
des Mots, 7/95:11-18, 1995. 




188 



N. Aussenac-Gilles, B. Biebow, and S. Szulman 



35. URL: http://imat.swi.psy.uva.nl/ofi/ofi.html. 

36. M. Uschold. Knowledge level modelling: concepts and terminology. The knowledge 
engineering review, 13/1:5-29, 1998. 

37. C. Vogel. Genie cognitif. Masson, Paris, 1988. 




Mining Ontologies from Text 



Alexander Maedche and Steffen Staab 

AIFB, Univ. Karlsruhe, D-76128 Karlsruhe, Germany 
{maedche , staab}@aif b . uni-karlsruhe . de 
http: //www. aifb .uni-karlsruhe . de/WBS 



Abstract. Ontologies have become an important means for structuring 
knowledge and building knowledge-intensive systems. For this purpose, 
efforts have been made to facilitate the ontology engineering process, in 
particular the acquisition of ontologies from domain texts. We present a 
general architecture for discovering conceptual structures and enginee- 
ring ontologies. Based on our generic architecture we describe a case 
study for mining ontologies from text using methods based on dictio- 
naries and natural language text. The case study has been carried out 
in the telecommunications domain. Supporting the overall text ontology 
engineering process, our comprehensive approach combines dictionary 
parsing mechanisms for acquiring a domain-specific concept taxonomy 
with a discovery mechanism for the acquisition of non-taxonomic con- 
ceptual relations. 



1 Introduction 

Ontologies^ have shown their usefulness in application areas such as intelligent 
information integration [23], information brokering [20] and natural-language 
processing [21], to name but a few. However, their wide-spread usage is still hin- 
dered by ontology engineering being rather time-consuming and, hence, expen- 
sive. A number of proposals have been made to facilitate ontological engineering 
through automatic discovery from domain data, domain-specific natural langu- 
age texts in particular (cf. [1,3,5,13,14,16,24]). However, most approaches have 
“only” tackled one step in the overall ontology engineering process, e.g. the acqui- 
sition of concepts, the establishment of a concept taxonomy or the discovering of 
non-taxonomic conceptual relationships, whereas one must consider the overall 
process when building real-world applications. 

In this paper we describe a case study for mining ontologies from textual 
resources, viz. from technical dictionaries and from domain texts, where we con- 
sider all three before-mentioned steps. For this purpose we combine existing 
techniques for the acquisition of concepts and a concept taxonomy with a new 

^ We restrict our attention in this paper to domain ontologies that describe a parti- 
cular small model of of the world as relevant to applications, in contrast to top-level 
ontologies and representational ontologies that aim at the description of generally ap- 
plicable conceptual structures and meta-structures, respectively, and that are mostly 
based on philosophical and logical point of views rather than focused on applications. 



R. Dieng and O. Corby (Eds.): EKAW 2000, LNAI 1937, pp. 189-202, 2000. 
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approach for mining non-taxonomic conceptual relationships from natural lan- 
guage in an integrated framework for manual and semi-automatic ontology en- 
gineering. 

The remainder of the paper is as follows. In Section 2 we will give an overview 
of the overall system architecture, in particular about which linguistic processing 
has been done and how discovered conceptual structures are added to the onto- 
logy using a graphical ontology engineering environment. Subsequently, we will 
focus on the techniques for acquiring concepts and concept hierarchies which are 
an essential part for the algorithm discovering non-taxonomic conceptual relati- 
ons. This algorithm will be presented in Section 4. An example will show some 
promising results we obtained applying our mechanisms for mining ontologies 
from text. Before we conclude we give an overview of related work in Section 5. 



2 Architecture 

The purpose of this section is to give an overview of the architecture of our ap- 
proach. The process of semi-automatic ontology acquisition is embedded in an 
application that comprises several core features described as a kind of pipeline in 
the following. Nevertheless, the reader may bear in mind that the overall develop- 
ment of ontologies remains a cyclic process (cf. [12]). In fact, we provide a broad 
set of interactions such that the engineer may start with primitive methods first. 
These methods require very little or even no background knowledge, but they 
may also be restricted to return only simple hints, like term frequencies. While 
the knowledge model matures during the semi-automatic engineering process, 
the engineer may turn towards more advanced and more knowledge-intensive 
algorithms, such as our mechanism for discovering generalized relations. 

2.1 Text & Processing Management Component 

The ontology engineer uses the Text & Processing Management component to 
select domain resources (dictionaries, domain texts, . . . ) exploited in the furt- 
her discovery process. She chooses among a set of text (pre-)processing methods 
available on the Text Processing Server and among a set of algorithms availa- 
ble at the Learning & Discovering component. The former module returns text 
that is annotated by XML and this XML-tagged text is fed to the Learning & 
Discovering component described in subsection 2.3. 

2.2 Text Processing Server 

The Text Processing Server comprises a broad set of different methods. In 
our case, it contains a shallow text processor based on the core system SMES 
(Saarbriicken Message Extraction System; cf. [15]). SMES is a system that per- 
forms syntactic analysis on natural language documents. In general, the Text 
Processing Server is organized in modules, such as a tokenizer, morphological 
and lexical processing, and chunk parsing that use lexical resources to produce 
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semi-staictured information, 




Fig. 1. Architecture of the Ontology Learning Environment 



mixed syntactic/semantic information. The results of text processing are stored 
in annotations using XML-tagged text. 

SMES is a generic component that adheres to several principles that are 
crucial for our objectives, (i), it is fast fast and robust, (ii), it yields “normalized” 
terms, and, (in), it returns pairs of concepts the coupling of which is motivated 
through linguistic constraints on the corresponding textual terms. In addition, we 
made some minor changes such that principle (iv), linguistic processing delivering 
a high recall on the number of dependency relations occuring in a text, is also 
guaranteed. 

The Architecture of SMES comprises a tokenizer based on regular expressi- 
ons, a lexical analysis component including a word and a domain lexicon, and a 
chunk parser. 

Tokenizer. Its main task is to scan the text in order to identify boundaries of 
words and complex expressions like “$20.00” or “Baden-Wuerttemberg”^, and 
to expand abbreviations. 

Lexicon. The lexicon contains more than 120.000 stem entries and more than 
12,000 subcategorization frames describing information used for lexical analysis 
and chunk parsing. Furthermore, the domain-specific part of the lexicon asso- 
ciates word stems with concepts that are available in the concept taxonomy. 



^ Baden- Wuerttemberg is a region in the south west of Germany. 
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The reader may note that at the beginning there are no or only few mappings 
from word stems to (some few, domain-independent) concepts available in the 
domain lexicon. Only with the extension of the ontology the domain-specific part 
of the lexicon is augmented, too.^ At the beginning the ontology engineer uses 
simple means, e.g. word counts, in order to establish new concepts and their 
linkages to word stems. By doing so, she leverages the linguistic processing and, 
thus, the further knowledge discovery process in subsequent stages. 

Lexical Analysis uses the lexicon to perform, (1), morphological analysis, z.e., 
the identification of the canonical common stem of a set of related word forms 
and the analysis of compounds, (2), recognition of name entities, (3), retrieval 
of domain-specific information, and, (4), part-of-speech tagging: 

1. In German compounds are extremely frequent and, hence, their analysis into 
their parts, e.g. “database” becoming “data” and “base”, is crucial and may 
yield interesting relationships between concepts. Furthermore, morphological 
analysis returns possible readings for the words concerned, e.g. the noun and 
the verb reading for a word like “man” in “The old man the boats.” 

2. Processing of named entities includes the recognition of proper and company 
names like “Deutsche Telekom AG” as single, complex entities, as well as the 
recognition and transformation of complex time and date expressions into a 
canonical format, e.g. “January 1st, 2000” becomes “1/1/2000”. 

3. The next step associates single words or complex expressions with a concept 
from the ontology if a corresponding entry in the domain-specific part of 
the lexicon exists. E.g., the expression “Deutsche Telekom AG” is associated 
with the concept TKCompany. 

4. Finally, part-of-speech tagging disambiguates the reading returned from mor- 
phological analysis of words or complex expressions using the local context. 

Lexical analysis is the first of two primary outputs from SMES that we ex- 
ploit. It returns “normalized” readings for different word forms (e.g., singular vs. 
plural) that we want to abstract from in order to add a corresponding concept 
to the ontology. 

Chunk Parser. SMES uses weighted finite state transducers to efficiently pro- 
cess phrasal and sentential patterns. The parser works on the phrasal level, 
before it analyzes the overall sentence. Grammatical functions (such as subject, 
direct-object) are determined for each dependency-based sentential structure on 
the basis of subcategorizations frames in the lexicon. 

The chunk parser of SMES returnes the second primary output that we use, 
viz. dependency relations [9] found through lexical analysis (compound proces- 
sing) and through parsing at the phrase and sentential level. We take advan- 
tage of the fact that syntactic dependency relations coincide rather closely with 
semantic relations holding between the very same entities (cf. [6]). Thus, we 
consider syntactic results as the signposts that points our discovery algorithms 
into the direction of semantic relationships. We feed those conceptual pairs to 

® In the future, we also want to extend the lexicon proper during domain adaptation. 
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the learning algorithm the corresponding terms of which are dependentially rela- 
ted. Thereby, the grammatical dependency relation need not even hold directly 
between two conceptually meaningful entities. For instance, once we have the 
linkages between “France Telecom” and “Paris” denoting instances of Company 
and City, respectively, in example (1), we may conjecture a semantic relationship 
between Company and City. The motivation is derived from the dependential re- 
lationships between “France Telecom”, “in”, and “Paris”. The preposition “in” 
acts as a mediator that incurs the conceptual pairing of Company with City (cf. 
[17] for a comprehensive survey of mediated conceptual relationships). 

(1) France Telecom in Paris offers the new DSL technology. 

Heuristics. Chunk parsing such as performed by SMES still returns many phra- 
sal entities that are not related within or across sentence boundaries. This howe- 
ver means that our approach would be doomed to miss many relations that often 
occur in the corpus, but that may not be detected due to the limited capabilities 
of SMES. For instance, it does not attach prepositional phrases in any way and 
it does not handle anaphora, to name but two desiderata. We have decided that 
we needed a high recall of the linguistic dependency relations involved, even if 
that would incur a loss of linguistic precision. The motivation is that with a 
low recall of dependency relations the subsequent algorithm may learn only very 
little, while with less precision the learning algorithm may still sort out part of 
the noise. Therefore, the SMES output has been extended to include heuristic 
correlations beside linguistics-based dependency relations: 

— The NP-PP -heuristic attaches all prepositional phrases to adjacent noun 
phrases. 

— The sentence-heuristic relates all concepts contained in one sentence if other 
criteria fail. This is a crude heuristic that needs further refinement. However, 
we found that it yielded many interesting relations, e.g. for enumerations, 
which could not be parsed successfully. 

Thus, these heuristics complement the output produced by the chunk parser. 
To sum up, linguistic processing outputs “normalized” terms and sets of con- 
cept pairs, CP := {(oi^, ai^ 2 )\ai,j G C}. Normalization is based on lexical analy- 
sis and the coupling of concepts is motivated through various direct and mediated 
linguistic constraints or by several general or domain-specific heuristic strategies. 

2.3 Learning & Discovering Component 

The Learning & Discovering component uses various algorithms on the annotated 
texts: 

1. Conventional term extraction mechanisms are applied to extract relevant 
terms from the corpus. 

2. An approach for mining a concept taxonomy from a dictionary, which is 
based on regular expression-based pattern matching algorithms, described 
in further detail in Section 3 
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3. An approach for mining non-taxonomic relations, that uses the learning al- 
gorithm for discovering generalized association rules described in Section 4. 
Conceptual structures that exist at learning time (e.g. concepts or a concept 
taxonomy) may be incorporated into the learning algorithms as background 
knowledge. The evaluation of the applied algorithms such as described in [13] is 
performed in a submodule based on the results of the learning algorithm. 



2.4 Ontology Engineering Environment OntoEdit 

The Ontology Engineering Environment OntoEdit, a submodule of the Ontology 
Learning Environment “Text-To-Onto” (cf. Figure 2), supports the ontology 
engineer in semi-automatically adding newly discovered conceptual structures 
to the ontology."* In addition to core capabilities for structuring the ontology, 
the engineering environment provides some additional features for the purpose of 
documentation, maintenance, and ontology exchange. OntoEdit internally stores 
ontologies using an XML serialization of the ontology model. OntoEdit accesses 
an inference engine that is based on Frame-Logic.® 

2.5 System Wrap-Up 

The principle idea of our framework is based on applications of knowledge dis- 
covery techniques based on input from linguistic processing in a semi-automatic 
bootstrapping approach. The learning mechanisms in our system do not de- 
termine the complete structure, but they are only meant to help the ontology 
engineer with building a domain ontology by giving recommendations for adding 
concepts or relations. The system is also not intended to be used in a pipeline 
fashion, but rather we conceive that simple methods should be exploited first in 
order to determine the scope of the ontology and the set of relevant concepts. 
With the extension of the ontology, conceptual and linguistic resources are aug- 
mented and, thus, they nourish more complex and fruitful linguistic processing 
and knowledge discovery in subsequent passes through the ontology learning and 
engineering cycle. 

3 Mining a Concept Taxonomy from a 
Telecommnnications Dictionary 

In order to provide a starting set of concepts and their taxonomic relations for 
the domain ontology of our case study, we have exploited the structuring of a 

* A comprehensive description of the ontology engineering system OntoEdit and the 
underlying methodology is given in [22]. 

® F-Logic is a frame- logic representation language conceived by [10]. In the implemen- 
tation by Angele and Decker that we use, F-Logic is a proper subset of first-order 
predicate logic. Concepts and relations are reified and, hence, may be treated as first- 
order objects over which quantification is possible. For efficient processing, F-Logic 
is translated into a datalog-style representation (cf. [11,2]). 
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Fig. 2. OntoEdit 



freely available dictionary from the telecommunications domain in the first step. 
In order to make use of the resulting ontology as input for the discovery of 
further conceptual relations (cf. Section 4), we also had to acquire the mapping 
between concepts and words. 



Example 

A dictionary containing natural-language definitions of terms in the telecommu- 
nications domain, which is freely available at 

http://www.mterest.de/online/tkglossar/index.html, served as a good starting point 
for the case study. The given 1465 HTML pages were downloaded and transfor- 
med into our predefined XML representation for dictionaries, such as given in 
the following small example: 

<termEntry> 

<admin> 

<entrynumber>1328</entrymimber> 

</ admin> 

<term lang=’Deutsch’> Kommunikationsserver 
<description type=’Definition’> 

<de s cr ipt i onT ext > 

Zentrale Funktionseinheit , welche fuer 




196 



A. Maedche and S. Staab 



mehrere Benutzer Kommunikationsdienste erbringt . 
</descriptionText> 

</description> 

</term> 

</termEntry> 

Every entry has been defined as a concept and a corresponding domain lexi- 
con entry of this concept (reduced to its word stem) has been generated using 
the Text Processing Server lexical analysis. The definitions of the terms have 
also been processed using the Text Processing Server. 

Similar to the work described in [8,14], we have defined several lexico-syn- 
tactic patterns in the form of regular expressions for extracting ISA relations 
between concepts on the given processed and normalized dictionary definitions. 
In our small example above the following simple pattern, which is expressed in 
natural language here for ease of presentation, matched: 

’’the last NP of the definition before the last comma represents a hypernym 
of the concept to be defined” 

The patterns have resulted in ISA relations, such as between the concept 
Kommunikationsserver (engl. communication server) and Funktionseinheit (engl. fun- 
ctional unit). 

However, we have to emphasize that for building a representative domain 
ontology, the described dictionary parsing mechanisms are not sufficient. Typi- 
cally, domain-specific dictionaries describe terms only at a very detailed technical 
level focusing on the leaf concepts of the taxonomy. For instance, the above men- 
tioned dictionary lacked many important concepts, such as private customer and 
business customer. For this reason, we have also applied term extraction mecha- 
nisms based on the tfidf measure [18] on the given corpus in order to propose 
frequent terms as candidate concepts. These concepts were then added manually 
to the domain ontology. 

This mixed approach using a combination of automatic extraction mecha- 
nisms and user modeling resulted in an core ontology with 265 concepts connec- 
ted through 312 ISA relations. Additionally, 620 domain lexicon entries mapping 
words to concepts have been brought into the system. 

4 Mining Generic Relations from Text 

Our text mining mechanism for discovering relations between concepts is based 
on the algorithm for discovering generalized association rules proposed by Srikant 
and Agrawal [19]. Their algorithm is used for well-known applications of data 
mining, viz. finding associations that occur between items, e.g. supermarket 
products, in a set of transactions, e.g. customers’ purchases. The algorithm aims 
at descriptions at the appropriate level of abstraction, e.g. “snacks are purchased 
together with drinks” rather than “chips are purchased with beer” and “peanuts 
are purchased with soda” . The basic association rule algorithm is provided with 
a set of transactions T := {ti\i = 1 . . .n}, where each transaction ti consists of 
a set of items ti := = 1 . . .mi,aij € C} and each item Oij is from a set 
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of concepts C. The algorithm computes association rules C 

C,Xk n Yfc = {}) such that measures for support and confidence exceed user- 
defined thresholds. Thereby, support of a rule Xk ^ Yfc is the percentage of 
transactions that contain Xk U Yfc as a subset, and confidence for Xk Yk is 
defined as the percentage of transactions that Yk is seen when Xk appears in a 
transaction, viz. 

(2) support(Xfc ^ Yk) = 

(3) co„fld»ce(Ar ^ n) = 5 

Srikant and Agrawal have extended this basic mechanism to determine asso- 
ciations at the right level of a taxonomy, formally given by a taxonomic relation 
H C CxC. For this purpose, they first extend each transaction ti to also include 
each ancestor of a particular item Uij, i.e. t' := ti U {ai,/|(aij, € H}. Then, 

they compute confidence and support for all possible association rules Xk Yk 
where Yk does not contain an ancestor of Xk as this would be a trivially valid 
association. Finally, they prune all those association rules Xk Yk that are 
subsumed by an “ancestral” rule Xk Yk, the itemsets Xk,Yk of which only 
contain ancestors or identical items of their corresponding itemset in Xk Yk- 
For the discovery of conceptual relations we may directly build on their 
scheme, as described in the following four steps that summarize our learning 
module: 

1. Determine T := {{oip, , ai,m'}|(ai,i, 0 ^, 2 ) G CP A 

? > 3 — >■ ((fli,!, G V {ai^2,di,l) G H)}. 

2. Determine support for all association rules Xk Yk, where |Afc| = \Yk \ = 1. 

3. Determine confidence for all association rules Xk Yk that exceed user- 
defined support in step 2. 

4. Output association rules that exceed user-defined confidence in step 3 and 
that are not pruned by ancestral rules with higher or equal confidence and 
support . 

The reader may note that we here have chosen a baseline approach conside- 
ring the determination of the set of transactions T. Actually, one may conceive 
of many strategies that cluster multiple concept pairs into one transaction. 

For instance, let us assume a set of 100 texts each describing a particular 
client in detail. Each private client might come with an address, but it might also 
have an elaborate description of the different types of private telecomunication 
services and different calling types resulting in 10,000 concept pairs returned 
from linguistic processing. Our baseline choice considers each concept pair as 
a transaction. Then support for the rule {PrivateClient}=^>{Address} is equal or, 
much more probably, (far) less than 1%, while rules about telecommunication 
services and different calling types might achieve ratings of several percentage 
points. This means that an important relationship between {PrivateClient} and 
{Address} might get lost among other conceptual relationships. In contrast, if one 
considers complete texts to constitute transactions, an ideal linguistic processor 
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might lead to more balanced support measures for {PrivateClient}=>{Address} and 
{Service}=^{CallingType} of up to 100% each. 

Thus, discovery might benefit when background knowledge about the domain 
texts is exploited for compiling transactions. In the future, we will have to further 
investigate the effects of different strategies. 

Example 

For the purpose of illustration, we here give a comprehensive example, which 
is based on our actual experiments. We have generated a text corpus by cra- 
wling texts from several WWW providers for telecommunications information 
(URL: http://www.TK-news.de/). The corpus describes actual objects, like tel- 
ecommunication companies, new technologies, telecommunication services, and 
trends, such as given in the following example sentences. 

(4) a. France Telecom bietet als erster Telekommunikationsdienstleister das 
DSL-Netz mit maximaler Uebertragungsgeschwmdigkeit. 

b. Die Swiss Telekom Beteiligungsgesellschaften erschweren den Fortschritt. 

c. Laut interner Information wird France Telecom mit der BCDM AG mer- 

gen. 

d. Alle Basisanschluesse sind mit Kabel, Telefon und PC-Karte ausgestattet. 

Processing the example sentences (4a) and (4b), SMES (Section 2) outputs 
dependency relations between the terms, which are indicated in slanted fonts 
(and some more). In sentences (4c) and (4d) the heuristic for prepositional 
phrase-attachment and the sentence heuristic relate pairs of terms (marked by 
slanted fonts), respectively. Thus, four concept pairs - among many others - are 
derived with knowledge from the domain lexicon (cf. Table 1). 



Table 1. Examples for linguistically related pairs of concepts 



Termi 


ai,i 


Term2 


ai,2 


DSL-Netz 


DSLNetz 


Ueb.geschwindigkeit 


Uebgeschwindigkeit 


Swiss Telekom 


TKCompany 


Bet.gesellschaft 


Bet.gesellschaft 


France Telecom 


TKCompany 


BCDM AG 


TKCompany 


Basisanschl uss 


Basisanschluss 


Kabel 


Kabel 



The algorithm for learning generalized association rules (cf. Section 4) uses 
our semi-automatically generated domain taxonomy, an excerpt of which is 
depicted in Figure 3, and the concept pairs from above (among many other 
concept pairs). In our actual experiments, it discovered a large number of inte- 
resting and important non-taxonomic conceptual relations. 

A few of them are listed in Table 2. Note that in this table we also list a 
conceptual pair, viz. (private client, city), that is not presented to the user, but 
which is pruned. The reason is that there is an ancestral association rule, viz. 
(client, city), with higher confidence and support measures. 
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Fig. 3. An example scenario 
Table 2. Examples of discovered relations 



Discovered relation Confidence Support 



(market, tariff) 


0.38 


0.04 


(connection, price) 


0.39 


0.03 


(TKCompany, TKCompany) 


0.5 


0.1 


(client, city) 


0.39 


0.03 


(private client, city) 


9.39 


om 



5 Related Work 

The objective of our framework is to facilitate ontology engineering from texts 
in real-world settings through several information extraction and learning ap- 
proaches. Thus, we had to face (i) the discovery of relevant concepts, (ii) their 
organization in a taxonomy, and (iii) the non-taxonomic relationsships between 
concepts. 

In our actual case study, we have employed a three-step approach. We have 
exploited some fairly well-known methods for concept discovery and organiza- 
tion, such as standard statistics-based approaches for term extraction [18] and 
the use of lexico-syntactic patterns on machine-readable dictionaries [8,14]. 

Based on the concept hierarchy from the first two steps, we have set a new 
method for the discovery of non-taxonomic relations on top. Regarding this part 
of our work, we want to give a more detailed survey of related work. 

Most researchers in the area of discovering conceptual relations have “only” 
considered the learning of taxonomic relations. To mention but a few, we refer 
to some fairly recent work, e.g., by Hahn & Schnattinger [5] and Morin [14] 
who used lexico-syntactic patterns with and without background knowledge, 
respectively, in order to acquire taxonomic knowledge. 

For purposes of natural language processing, several researchers have looked 
into the acquisition of verb meaning, subcategorizations of verb frames in parti- 
cular. Resnik [16] has done some of the earliest work in this category. His model 
is based on the distribution of predicates and their arguments in order to find 
selectional constraints and, hence, to reject semantically illegitimate propositi- 
ons like “The number 2 is blue.” His approach combines information-theoretic 
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measures with background knowledge of a hierarchy given by the WordNet taxo- 
nomy. He is able to partially account for the appropriate level of relations within 
the taxonomy by trading off a marginal class probability against a conditional 
class probability. He considers the question of finding appropriate levels of ge- 
neralization within a taxonomy to be very intriguing and concedes that further 
research is required on this topic (cf. p. 123f in [16]) . 

Faure and Nedellec [3] have presented an interactive machine learning system 
called ASIUM, which is able to acquire taxonomic relations and subcategoriza- 
tion frames of verbs based on syntactic input. The ASIUM system hierarchically 
clusters nouns based on the verbs that they co-occur with and vice versa. 

Wiemer-Hastings et al. [24] aim beyond the learning of selectional constraints, 
as they report about inferring the meanings of unknown verbs from context. 
Using WordNet as background knowledge, their system, Camille, generates hy- 
potheses for verb meanings from linguistic and conceptual evidence. A statistical 
analysis identifies relevant syntactic and semantic cues that characterize the se- 
mantic meaning of a verb, e.g. a terrorist actor and a human direct object are 
both diagnostic for the word “kidnap” . 

The proposal by Byrd and Ravin [1] comes closest to our own work. They 
extract named relations when they find particular syntactic patterns, such as an 
appositive phrase. They derive unnamed relations from concepts that co-occur 
by calculating the measure for mutual information between terms — rather 
similar as we do. Eventually, however, it is hard to assess their approach, as 
their description is rather high-level and lacks concise definitions. 

To contrast our approach with the research just cited, we want to mention 
that all the verb-centered approaches may miss important conceptual relations 
not mediated by verbs. All of the cited approaches except [16] neglect the im- 
portance of the appropriate level of abstraction. 

6 Conclusion 

In this paper we have presented an approach towards mining ontologies from 
natural language. We have considered a domain-specific dictionary as well docu- 
ments taken from the telecommunications domain as relevant resources for the 
difficult task of ontology learning. 

For the future much work remains to be done. First, we need to investigate 
what specific types of linguistic and heuristic output are best suited to optimize 
performance. Maybe chunk parsing does not even help so much, but noun phrase 
recognition does, or vice versa. Second, we are planning a study to investigate our 
defined evaluation and similarity measures precision, recall, and RLA described 
in [13] for that human modelers achieve when they are given the same task as our 
discovery mechanism. Third, we will have to investigate the influence of different 
transaction definitions (cf. Section 4) . Fourth, several existing ontologies such as 
WordNet [4] and the german counterpart GermaNet [7] have to be integrated as 
a core resource into the cyclic approach and mechanisms for pruning ontologies 
to the relevant domain have to be developed. Finally, and probably the most 
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intricate, we want to approach not only the learning of the existence of relations, 
but also their names and types. 
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Abstract. Using semantic knowledge in NLP applications always improves 
their competence. Broad lexicons have been developed, but there are few 
resources which contain semantic information available for words and which 
are non-dedicated to specialized domains. In order to build such a base, we 
designed a system, SVETLAN’, able to learn categories of nouns from texts, 
whatever their domain. In order to avoid general classes mixing all the 
meanings of words, they are learned taking into account the contextual use of 
words. 



1 Introduction 

Improving the competence of NLP applications and Information Research systems 
requires to develop more and more in-depth analysis of documents in order to capture 
their meaning more precisely. In NLP, existing techniques correspond to two kinds of 
approaches, radically different. On one hand, surface analysis of texts is based on the 
distribution of words and their importance in a corpus. It exploits lexical knowledge 
on words and, possibly, general semantic information such as the semantic classes of 
a word and relations between words or concepts, as those found in WordNet [7] or in 
thesauri. This kind of approach can be applied to large text bases, whatever their 
subjects. In return, it does not allow these systems to develop a detailed and precise 
analysis, due to the lack of a precise and structured knowledge base. Even when using 
WordNet, this problem remains. Words in WordNet are related to a Synset when they 
are synonymous, however Synsets correspond to large categories, and there exists 
some shifts of meaning between two synonyms so that when two words belonging to 
a same Synset are considered within a specific context, they often no longer share a 
common meaning. 

On the other hand, in-depth understanding systems require highly structured 
semantic knowledge as well as pragmatic knowledge about situations referred in texts 
(the events, their causal links and characters). These systems aim at developing 
semantic analysis of sentences and building a representation of the meaning of texts. 
Their limitation comes from these required resources that are impossible to build 
except in very limited and well-known domains. The problem we address in this 
paper is then to improve the first systems, in order to go towards the second ones, but 
without losing the large coverage of the first ones. This is done by automatically 
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acquiring a more structured knowledge base than the bases presently used. Our goal is 
to extract knowledge from texts, considering that they contain many examples of 
word uses. We do not want to model a specialized domain, a priori chosen. On the 
contrary, we want to process “general” language, as opposed to a specialized 
language, but it is well known that there is no "general language corpus". Each corpus 
is a subpart of the language that has its own specificity. Thus we use a corpus made of 
newspaper articles (French Agence France Presse {AFP) newswires and “Le Monde” 
articles). This corpus covers a wide range of different subjects and so, is close to what 
would be a "general language corpus", apart from the quite fixed journalistic style. 

Automatic processes that extract knowledge from texts belong to statistical or 
syntactical approaches with a lot of variations between these two extremes. Purely 
statistical ones, such as [15] often obtain groups of words that characterize a sense of 
a target word. Other approaches ([1], [6], [10], [11], [14]) are more syntactical and 
obtain classes of words with similar meanings': ARIOSTO [1] and STARTEX [14] 
use manual semantic tagging and next classification, but while STARTEX uses not 
tagged repeated text segments, ARIOSTO uses syntactically parsed text. On the 
contrary ASIUM [6] applies a cooperative clustering algorithm on classes obtained 
from syntactically parsed texts. ZELLIG [11] constructs a graph of words linked by 
their common contexts in elementary noun phrases. By the study of the characteristics 
of this graph, it builds semantic categories. These three systems are designed to work 
on specialized languages belonging to a specific domain, whose vocabulary is well 
defined and generally not very ambiguous. When applied to non-specialized texts, 
they lead to build large classes, mixing all the meanings of words^, as shown by Fabre 
et al. [5] for ZELLIG. 

As newspapers articles contain a lot of polysemous words, these approaches cannot 
be applied directly, because they are more or less based on the assumption that their 
target corpus is sufficiently specialized to be able to ignore the problem of polysemy. 
Flowever, when considering these polysemous words in their contextual use, i.e. a 
segment of text about only one topic, their meaning is no more ambiguous. Thus, our 
system, SVETLAN’, takes advantage of a precise context recognition ability in order 
to build homogeneous classes of words despite the generality of the corpus. It is based 
on a distributional approach: nouns playing the same syntactic role with a verb in 
sentences related to the same topic, i.e. the same domain, are aggregated in the same 
class. The contextual approach of SVETLAN’ relies on knowledge about semantic 
domains of texts, automatically learned by SEGAPSITH [9]. This is way of focusing 
the construction of the classes by reference to controlled topics. It allows our system 
to deal naturally with more general texts while giving classes of words with similar 
meanings, in comparison with the other approaches which have to process specialized 
texts or that give more disjoined classes. 



' In the rest of this paper, we use the term Vords with similar meanings’ to identify words that 
refer to concepts with an immediate, or quasi-immediate, ancestor in a conceptual ontology. 

^ Pereira et al. [13] use also syntactically parsed texts and a statistical clustering algorithm but 
applied to more general texts: Associated Press newswires. Classes obtained do not seem to 
constitute synonym sets as those of the preceding systems, but they have been used 
successively on a disambiguation task. 
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2 Overview of the System 

Input data of SVETLAN’ (see Fig. 1) are semantic domains with the Thematic Units 
(TUs) that have given birth to them. TUs are the result of a topic segmentation 
process relying on lexical cohesion that processes texts such as newspaper articles. 
Each TU contains the lemmatized content words of a text segment. The domains are 
automatically learned by aggregating similar thematic units. So, domains are sets of 
weighted words, relevant to represent a specific topic. 




Fig. 1. Schema of structured domain learning 



The first step of SVETLAN’ consists of retrieving text segments of the original 
texts associated to the different TUs in order to parse their sentences. SVETLAN’ 
extracts triplets from the parser results, that are constituted by a verb, the head noun 
of a phrase and its syntactic role. Thus, to each TU corresponds a text segment and a 
set of triplets we call a structured thematic unit. In order to build classes of nouns 
according to their contextual use, only the structured thematic units associated to a 
same semantic domain are aggregated altogether. Aggregation consists of grouping 
nouns playing the same syntactic role with a same verb. In such an approach, a verb 
associated to a type of phrase (subject, direct object, ...) constitutes a criterion for 
building categories. However, one can find words belonging to different semantic 
categories associated to a same verb and a same type of phrase when the verb is 
polysemous, as for example to drive a car and to drive a railway, the same problem 
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occurs with very general verbs, as to search for example, that do not entail alone a 
discrimination among their direct objects. Thus the application of a distributional 
method without any control coming from the context would lead the system to build 
heterogeneous categories. SVETLAN’ solves this problem by aggregating verb 
complements within TUs belonging to a same domain. That ensures a better 
homogeneity of the data and leads SVETLAN' to form context sensitive classes. A 
last filtering step, based on the weights of the words in their domain, allows the 
system to eliminate nouns from classes when they are not very relevant in this 
context. This whole process leads to the formation of structured domains, i.e. 
semantic domains where each verb is related to categories of nouns that are 
semantically homogenous. 



3 Semantic Domain Learning 

We only give here a brief overview of the semantic domain learning module. This one 
is described more precisely in [9]. This module incrementally builds topic 
representations, made of weighted words, from discourse segments delimited by 
SEGCOEILEX [8]. It works without any a priori classification or hand-coded pieces 
of knowledge. Processed texts are typically French newspaper articles coming from 
Le Monde or AFP. They are pre-processed to only keep their lemmatized content 
words (adjectives, single or compound nouns and verbs). 

The topic segmentation implemented by SEGCOHLEX is based on a large 
collocation network, built from 24 months of Le Monde newspaper, where a link 
between two words aims at capturing semantic and pragmatic relations between them. 
The strength of such a link is evaluated by the mutual information between its two 
words. The segmentation process relies on these links for computing a cohesion value 
for each position of a text. It assumes that a discourse segment is a part of text whose 
words refer to the same topic, that is, words are strongly linked to each other in the 
collocation network and yield a high cohesion value. On the contrary, low cohesion 
values indicate topic shifts. After delimiting segments by an automatic analysis of the 
cohesion graph, only highly cohesive segments, named Thematic Units (TUs), are 
kept to learn topic representations. This segmentation method entails a text to be 
decomposed in small thematic units, whose size is equivalent to a paragraph. 
Discourse segments, even related to the same topic, often develop different points of 
view. To enrich the particular description given by a text, we add to TUs those words 
of the collocation network that are particularly linked to the words found in the 
corresponding segment. 

Learning a complete description of a topic consists of merging all successive points 
of view, i.e. similar TUs, into a single memorized thematic unit, called a semantic 
domain, or simply a domain. Each aggregation of a new TU increases the system’s 
knowledge about one topic by reinforcing recurrent words and adding new ones. 
Weights on words represent the importance of each word relative to the topic and are 
computed from the number of occurrences of these words in the TUs. This method 
leads SEGAPSITH to learn specific topic representations as opposed to [12] for 
example whose method builds general topic descriptions as for economy, sport, etc. 
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mots 


words 


occ. 


weight 


juge dlnstruction 


examining judge 


58 


0.501 


detention 


police custody 


50 


0.442 


bien public 


public property 


46 


0.428 


charge 


charging 


49 


0.421 


emprisonner 


to imprison 


45 


0.417 


cour d’appel 


court of criminal appeal 


47 


0.412 


recel 


receiving stolen goods 


42 


0.397 


supposer 


to presume 


45 


0.382 


police judiciaire 


criminal investigation department 


42 


0.381 


ffaude 


fraud 


42 


0.381 



Fig. 2. The most representative words of a domain about justice 

We have applied the learning module of SEGAPSITH on one month (May 1994) 
of AFP newswires. Fig. 2 shows an example of a domain about justice that gathers 69 
TUs. In all figures displaying examples extracted from our results obtained on French 
texts, we will put the original data plus their literal English translation. 



Coequipier/Championnat 11 | 

( Team_mate/Championship) 



-Pilote/Formule 

{Pilot/Formula) 

Tennis/Coequipier 50 . 
( Tennis/Team_mate) 



Interpeller/Arrestation 6_ 
(To_question/Arrest) 



Monnaie/Trimestre 22_| 
{Mon ey/ Qua rter) 



t— Police/Policier 
{Police/Policeman) 

L Prison/Condamner 
{Jail/Condemn) 

Dollar/Milliard 

{Dollar/Billion) 



I Taux/Hausse 

{Rate/Rise) 



_Battre/Finale 

(To_beat/Finale) 

-Tour/Etape 

(Cycle_race/Stage) 



Fig. 3. Three hierarchies of semantic domains 

As some of these domains are close and refer to the same general topic, we have 
applied a hierarchical classification method based on their common words to organize 
them in separate general topics and to structure them. Fig. 3 shows the hierarchies 
built about sport, police and stock exchange. Each leaf is a domain, named by its two 
more weighted words, while their name and their size, i.e. the number of common 
words found in their children, describe internal nodes. 



4 Structured Domains Learning 



As in [6], verbs allow us to categorize nouns. Those nouns that play a same role 
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relative to a same verb define a class. In order to learn very homogeneous^ classes, we 
only apply this principle on words belonging to a same context, i.e. a domain. 



4.1 Syntactic Analysis 

In order to find the verbs and their arguments in the texts, we use the syntactic 
analyzer Sylex [3,4]. 



"L'etat de sante critique du pilote autrichien Karl Wendlinger (Sauber-Mercedes), victime d'un grave accident jeudi matin 
lors des premiers essais du Grand Prix de Monaco de Formule Un, laisse planer une menace sur le deroulement de la 
course, dimanche en Principaute." 

#♦#***#**!(!*!(!*!(!!(!***** \ 193-466 taux 4 ************************** 

"L'etat de sante critique du pilote autrichien Karl Wendlinger (Sauber-Mercedes), victime d'un grave accident jeudi matin 
lors des premiers essais du Grand Prix de Monaco de Formule Un, laisse planer une menace sur le deroulement de la 
course, dimanche en Principaute." 

<Lexico-Syntactic information> 

193-195 (164) "L"' "le" [gs.l,avn,pdet.l] pdet : singulier elision dmaj 

195-208 (165) "etat de sante" "etat de sante" [gs.l,nom.l] nom ; masculin singulier mot_compose locsw 
...<snip>.... 

382-388 (203) "laisse" "laisse" [gs.l2,nom.l] nom : feminin singulier 
389-395 (204) "planer" "planer" [gs.l3,verbe] verbe : infmitif 
...<snip>.... 

193-195 (16) "L"’ "le" [gs.l,avn,pdet.l] pdet : singulier elision dmaj 

195-208 (117) "etat de sante" "etat de sante" [gs.l,nom.l] nom : masculin singulier mot_compose locsw 
...<snip>.... 

382-388 (211) "laisse" "laisser" [gs. 13, verbe] verbe : singulier autoontif antiontif anontif present indicatif subjonctif 

imperatif 

389-395 (212) "planer" "planer" [gs. 14, verbe] verbe : infmitif 
...<snip>.... 

<Syntactic Links> 

'L'etat de sante critique' (164) ->- cn head ->- 'du pilote autrichien' (170) 

'planer' (204) ->- a2 head ->- 'une menace' (205) 

...<snip>.... 

'planer' (153) ->- a2 head ->- 'une menace' (154) 

...<snip>.... 

'planer' (161) ->- a2 head ->- 'une menace' (162) 

...<snip>.... 

'planer' (212) ->- a2 head ->- une menace' (213) 
sur le deroulement' (66) ->- cn head ->- de la course' (235) 

Fig. 4. An extract of an analysis of a sentence by Sylex (in French only). 

Fig. 4 shows a little part of the results of Sylex for a sentence. The first part 
exhibits lexico-syntactic information for the words and this for four different 
interpretations (indicated by the code “taux 4” = rate 4) due to the fact that Sylex 
cannot chose between two interpretations for two words: “laisse" between the verb 
“laisse/" (to let) and the noun “laisse" (leash) and “critique" between the verb 
“critique/" (to criticize) and the adjective “critique" (critical). The second part shows 
the syntactic links found by Sylex. Between parenthesis are references to the words in 
the preceding analysis. Here Sylex has found four times the same interpretation. In 
this case, we count one occurrence of the link. But if it finds several times the same 
relation between a verb and different words, for example several possible subjects, 
then we keep all the different interpretations. That is because we have no way to 



^ We call homogeneous a class that contains words that have similar meanings, as defined 
above, in the corresponding domain. 
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choose between them. We make the reasonable expectation that the false 
interpretations will have much less occurrences in the corpus and so, will be filtered 
out during the rest of the processing. 

The results of Sylex are very detailed and not easy to parse directly with, say, Perl. 
Furthermore, we do not need all the information it extracts. In fact, we only need to 
find the verb with its links and the head nouns arguments of these links. So, we have 
developed a formal grammar that extracts from these raw analyzes the associations 
between a verb and its arguments. This grammar extracts links from the results of 
Sylex in the following format: 

i#j verb # tokenl # /ewmaf # k rel # token2 # lemma2 # 1 
where i and j are the boundaries of the sentence that contains the link in the corpus; 
tokenl and lemmal are the token and the lemma of the verb respectively; rel is the 
syntactic relation which can be "subject", "direct object" or a preposition ("to", 
"from", etc.) ; token2 and lemma2 are the token and the lemma of the head noun of 
the noun phrase pointed by the relation; lastly, k and / are the indexes in the corpus of 
tokenl and token2 respectively. Fig. 5 shows some links that we have extracted. 



token 1 


lemme 1 




relation 


token 2 


lemme 2 


plane 


planer 




suiet 


menace 


menace 


joue 


jouer 




COD 


coupe 


coupe 


apprenons 


apprendre 




de 


sources 


source 




tokenl 


lemma! 




rel 


token! 


lemma2 


hang over 


hang over 




subiect 


threat 


threat 


play 


play 




object 


cup 


cup 


hear 


hear 






sources 


source 



Fig. 5. Examples of extracted links 



Sylex, as other syntactic analyzers, has problems with some constructions and 
consequently introduces errors that can cause problems to the remaining of the 
system. Some common errors are the bad interpretation of the passive form that 
causes a subject to be analyzed as a direct object and conversely, a direct object to be 
viewed as a subject. Another common error is that it often happens that Sylex does 
not find any link in a phrase. That is what we call silence. We will see in Sect. 5 that 
we can obtain good results despite these problems thanks to the redundancy needed to 
validate the links in the next steps of processing. But a consequence of this 
redundancy need is that the system must use great quantities of texts in order to create 
classes with a satisfactory size. 

Having obtained the syntactic links that were in the texts, we want to group them 
relatively to the belonging of their text segment to a Thematic Unit. So, we define a 
structured thematic unit as a set of <Verb~^ syntactic relation-^ Noun> structures, 
syntactic relations instantiated with a verb and a noun. We will refer to these 
structures as instantiated syntactic relations. We are able to put in relation the links 
extracted from the results of Sylex and the words contained in the domains because 
each domain in the thematic memory remembers which thematic units have been used 
to create it. In the same way, each thematic unit remembers the part of text it comes 
from. 





210 



G. De Chalendar and B. Grau 



4.2 Aggregation 

In order to construct groups of words with very similar meanings, we want to group 
the nouns appearing with the same syntactic role in relation to a verb inside a domain. 
Then, a structured domain is a set of <Verb~^ syntactic relation-^ Noun^,..., Noun> 
structures, i.e. a set of aggregated instantiated syntactic relation. 

Structured thematic units related to a same domain are aggregated altogether to 
form the structured domains. Aggregating a structured thematic unit within a 
structured domain consists of: 

• aggregating their instantiated syntactic relations that contain a same verb ; 

• adding new instantiated syntactic relations, i.e. adding new verbs with their 
arguments made of a syntactic relation and the lemmatized form of a noun. 



1 Structured Domain source \ 


to play [4] 


object 


cup [3], match [1] 


with 


ball [1] 


to win [2] 


subject 


player [1] 


object 


match [1] 


1 2 Instantiated Syntactic Relations sources | 


to play 


subject 

object 


champion 

match 


to lose 


object 


championship 



1 Structured Domain result \ 


to play [5] 


object 


cup [3], match [2] 


with 


ball [1] 


subject 


champion [1] 


to win [2] 


subject 


player [1] 


object 


match [1] 


to lose [1| 


object 


championship [1] 



Fig. 6. An example of the aggregation of an instantiated syntactic relation in a structured domain 

Fig. 6 shows the aggregation of a structured domain and two instantiated syntactic 
relations. This example shows all the possible effects of the aggregation. In the figure, 
bold elements represent new or updated data. Aggregating an instantiated syntactic 
relation in a structured domain that already contains the verb of the instantiated 
syntactic relation leads to increment the occurrence number of the verb, as for play in 
the example which occurred 4 times before the aggregation. Similarly, the occurrence 
number of common nouns related to the verb by the same relation are updated {match 
goes from 1 to 2), and new relations with their associated nouns are added to the verb. 
In the example, the subject champion with an occurrence of 1 is added. An 
instantiated syntactic relation with a new verb is simply added with an occurrence of 
1, as for <to lose-^ object-^ championship> . 

Classes of nouns in the produced structured domains contain a lot of words that 
disturb their homogeneity. These words often belong to parts of the various TUs at the 
origin of the structured domain that are not very related to the described topic. They 
correspond to a meaning of a verb scarcely used in the context defined by the domain. 





SVETLAN’ 211 



Another possibility is that the instantiated syntactic relation results from an error of 
Sylex. As these words are weekly weighted in the corresponding domains, the data 
can be fdtered: each noun that possesses a weight lower than a threshold is removed 
from the class. By this selection, we reinforce learning classes of words according to 
their contextual use. At this time the threshold is empirically chosen. In the future, we 
plan to automatically find the threshold. It would be fixed in order to maximize the 
score of a validation task we outline in Sect. 7. Fig. 7 shows two aggregated links 
obtained without filtering in its upper part and the filtered counterparts in its lower 
part. The link for the verb "to establish'’ has been completely removed while the link 
of the verb "to answer’ with the preposition "to’ has been reduced by the removing of 
"list’ . We can see on this example that this filtering is efficient: the verb "to establish’ 
is not very related to the domain of "nuclear weapons’ from which this example is 
taken and the usage of "to answer to a list’ has a very low probability. More details on 
the effects of the filtering will be given in the Results section. 



etablir 

repondre 

lisle 


COD 

a 


base, zone 
document, 


question, 




COD 


l*\or’o 




ClaUlll 

repondre 


a 


Uiiac, Z.U11C 

document, 


question. 



to establish 
to answer 


object 

to 


base, zone 

document, question, list 


to c'tablrh 






to answer 


to 


document, question, list 



Fig. 7. Two filtered aggregated links in a domain about nuclear weapons 

In the principle, the described operations are not very complicated. The difficulties 
come from the necessity to work with data coming from various tools. Furthermore, 
for performance and practical reasons, we do not apply the chain of tools text by text. 
The natural way to see the process would be to: 

• read a text, 

• extract the TUs from it, 

• extract the corresponding structured thematic units, 

• add each TU to its domain, 

• add each structured thematic unit to its corresponding structured domain. 

In fact, each computing step is done on the entire corpus and the results are next 
aligned. This allows us to save computation time because we do not have to run each 
one multiple times. But in return we have to deal with dictionaries and indexes for 
various files and tools. 
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5 Results 

The experiments we realized aim at showing that SVETLAN’ lead to learn classes of 
words which have similar meanings in the domain. To obtain such results we have 
chosen to run our system on one month of the French version of AFP wires, that 
forms a corpus stylistically coherent but that covers varied subjects with very 
polysemous and non specific verbs. 

The judgements about the quality of the classes obtained are now manual and made 
by ourselves. We will obviously need a better and more systematic validation 
approach in the future. We will sketch in Sect. 7 some possibilities we consider. 

The one month of AFP wires is made of 4,500,000 words and 48,000 sentences in 
6,000 texts. The thematic analysis gives 8,000 TUs aggregated in 2,000 domains. 
More details on these domains can be found in [9]. From these 48,000 sentences, 
Sylex extracts 117,000 different instantiated syntactic relations. 24,000 of these links 
concern subject, direct object, or circumstantial complements introduced by a 
preposition and are integrated in 1,531 structured domains. 

After aggregating, but before filtering, the system obtains 431 aggregated links 
with two or more arguments, equivalent to 43 1 word classes. Some of them, such as 
<to manufacture direct object bomb, weapon> are good. Nevertheless other 
classes are heterogeneous as <to return direct object territory, strip, context, 
synagogue> (here strip comes from the Gaza Strip), or clearly mix different meanings 
of a verb, like <to quit direct object base, government> which mixes together 
the meanings "to leave a place" and "to retire from an institution". For the two latter 
cases, one can see the interest to take into account the fact that the domains contain 
words with different weights representing their relevance to this domain. The higher 
the weight, the higher the relevance of this word in this domain. So we apply the 
aforesaid filter to our classes and retain only those with weights higher than a 
threshold. The class <territory, strip, context, synagogue> is corrected to <territory, 
strip> and < base, government> is removed. 

Among the wrong classes, some are due to errors of Sylex, as <to confer-^ direct 
object price, actor> where actor should be linked to to confer by the preposition 
to. The remaining errors are due to the extensive use of two different meanings of the 
verb in the same domain, as for: <to conduct/to manage ^ direct object 
delegation, negotiation> (in French: "conduire une negociation/une delegation"). This 
kind of error is inherent to the method we use and should be removed by other means. 
Note again that the correctness of the links have been manually judged by ourselves. 

We have tried two thresholds: 0.05 and 0. 1 . Fig. 8 details the results for both. 



Threshold 


Total 


Good 


Sylex errors 


Remaining errors 


0.05 


73 


46 

63% 


13 

18% 


14 

19% 


0.1 


38 


27 

71% 


7 

18% 


4 

11% 



Fig. 8. Results of the filtering for two thresholds 



After filtering, a lot of classes are removed but the remaining classes are well 
founded in most cases. An example of a retained class for both thresholds is: 

<to injured subject colonist, soldier> 
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With a threshold set to 0.1 rather than to 0.05, we retain only 38 links, but we gain 
8% in precision. If we ignore the errors due to Sylex, the real precision of SVETLAN’ 
is in the first case 78% and in the second case 87%. It shows the interest there is to 
choose a good threshold. 

Our experiments lead to homogeneous classes containing words having similar 
meanings, though these classes contain few words. In order to show the efficiency of 
building classes of words inside a domain, it is interesting to see what kind of classes 
would be obtained by the merging of all domains, that is to say: creating context-free 
classes. So, we have applied the same aggregation principle to the same corpus but 
without taking into account the domains. Just below, we show two classes for the verb 
“to replace”. The top one is made context-free and the bottom one is made inside a 
domain. This verb is very general, virtually everything can be replaced. 



remplacer 


COD 


texte, constitution, pantalon, combustible, loi, dinar, barre, 
film, circulation, juge, saison, appareil, parlement, bataillon, 
police, president, trade 


remplacer 


COD 


combustible, barre 


to replace 


object 


text, constitution, trousers, combustible, law, dinar, bar, film, 
circulation, judge, season, device, parliament, battalion, 
police, president, treaty 


to replace 


object 


combustible, bar 



The first group of words merges very different senses while the second class, much 
more little, is better because it contains words referring to very similar concepts: a bar 
of uranium is nuclear combustible. Another example is the following, for the verb “to 
attribute“: 



attribuer 


COD 


parole, prix, decoration, pape, responsabilite, television, 
attentat, lettre, contrat, ministre, jury, fond, autorite, note, 
bonus, bande, bombardement 


attribuer 


COD 


prix, decoration 


to attribute 


object 


talk, prize, decoration, pope, responsibility, television, 
attempt, letter, contract, ministry, jury, funds, authority, note, 
bonus, band, bombing 


to attribute 


object 


prize, decoration 



Obtaining meaningful classes with a corpus such as “AFP” shows the efficiency of 
our method. Moreover, we obtain cohesive classes for verbs very general and 
polysemous. 

Words are often polysemous or ambiguous. However, when used in context, they 
denote one meaning, and moreover this meaning is generally the same in different 
occurrences of a same context. When building classes according to their context, we 
avoid mixing all the meanings of a word in a same class. Such a result can be 
exhibited in the classes (law, constitution) and (law, article, disposition) in the 
juridical context, for the words “articles”, “constitution” and “disposition”. 
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6 Related Works 

There is a lot of works dedicated to the formation of classes of words. These classes 
have very various statuses. They can contain words belonging to the same semantic 
field or near synonymous. We give here some details about three approaches we cited 
in the introduction that are good examples of different approaches: manual, statistical 
and syntactical. 

WordNet [7] is a lexical database made by lexicographers. It aims at representing 
the sense of the bigger part of the lexicon. It is composed of Synsets. A Synset is a set 
of words that are synonymous. These Synsets are linked by IS A relations. Its 
coverage is large but this quality is, in a sense, its shortcoming. Indeed, the generality 
of its contents makes it difficult to use in real sized applications that are often 
centered on a domain. It rarely can be used without a lot of manual adaptation, even if 
some authors tried to relate automatically acquired lexical knowledge with it, for 
example [2]. 

IMToolset, by Uri Zemik [15], extracts, for a word, several clusters of words from 
text. Each of these clusters reflects a different meaning of the studied word. This 
extraction is done by scanning the local contexts of the word, the 10 words 
surrounding it in the texts. These signatures are statistically analyzed and clustered. 
The result is groups of words that are similar to our domains but more focused on the 
sense of a word alone. 

We have already stressed out some characteristics of ASIUM by D. Faure and C. 
Nedellec, but we give here some more details. ASIUM learns subcategorization 
frames of verbs and ontologies from text using syntactic analysis and a conceptual 
clustering algorithm. It analyses texts with Sylex and creates basic clusters of words 
appearing with a same verb and a same syntactic role or preposition, as do 
SVETLAN’. These basic classes are then clustered to create an ontology by the mean 
of a cooperative learning algorithm. The main difference with SVETLAN’ is this 
cooperative part: ASIUM critically depends on the expert that has to valid, and 
possibly split, the clusters made by the algorithm. As a consequence, it has to work on 
specific technical texts. As a consequence, ASIUM, applied on texts such as our AFP 
wires would certainly not have been able to extract good classes. Indeed, there is a lot 
of very polysemous words in these texts that take a precise meaning only in a 
sufficiently focused context, such as our domains. Furthermore, as each word does not 
occur a lot, the distance measure currently used in ASIUM would not allow grouping 
any cluster. 



7 Future Directions of Work 

We envisage two major directions of work that are closely related: the extension of 
our results and a real validation of them. 

At this time, the classes do not contain a lot of words. A way to enlarge them, and 
the more obvious one, is to process more texts in order to have more data. That will 
necessitate some modifications of the algorithm of domain building. At this time, we 
store all the thematic units and all the words in domains, even if they are never 
aggregated and so have always an occurrence number of one. Thus, the memory 
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usage is too important. We will set up a kind of "garbage collection" process to 
remove or maybe recycle old and not very aggregated domains. This will allow us to 
process much more texts and so enlarge classes in two directions: their sizes and the 
number of occurrences of words inside them. 

Another way could be to regroup classes that are related to the same verb, by the 
same syntactic relation in two domains belonging to the same hierarchy, i.e. a same 
more general context, assuming the words always have the same meaning. However 
this method has to be tested on more results in order to prove its reliability. With our 
results, we would build for example (law, constitution, article, disposition) in the 
domain of “Law” and (rebel, force, northerner, leader) in the domain of “conflict”. 
This way of enlarging the classes should be studied carefully in a theoretical point of 
view. Indeed, the originality of our work is the focused context entailed by the use of 
the domains. That allows us to deal with texts from general language. When we 
consider domains in the same hierarchy, we enlarge the context and so, we take the 
risk to have the same problems as other works, discussed in the introduction and 
Sect. 6, when they are applied to general language: the merging in a same class of 
different meanings of some words. 

Another possibility to enlarge our classes is to generalize them as in ASIUM. 
ASIUM merges classes independently of the related verbs according to a similarity 
measure, even if, in our case, this generalization process would operate in a same 
general domain. Afterwards, as in ASIUM, we would ask an expert to validate its 
results. The problem would be, again, to find an expert of "general language". 

Concerning the validation task, it could be realized by relating our classes to 
existing classifications, as do [2] with WordNet. Another possibility would be to 
evaluate the improvement SVETLAN' permits when performing a task. Our group 
participates to the "Question Answering" track in the TREC evaluations and uses a 
search engine to find documents able to contain the answers. The questions of the QA 
track are about various topics from a newspaper corpus. So, we believe that the 
classes obtained by SVETLAN' could be very useful to extend precisely the requests 
to the search engine. 



8 Conclusion 

The system SVETLAN' we propose, in conjunction with SEGAPSITH and the 
syntactic parser Sylex, extracts classes of words from raw text. Instead of just having 
sets of weighted words for describing semantic domains, domains are described by a 
set of verbs related to classes of words by a syntactic link. These classes are created 
by the gathering of nouns appearing with the same syntactic role after the same verb 
inside a context. This context is made by the aggregation of text about similar 
subjects. Besides, we can also view this base as semantic classes, each one being 
related to its context of interpretation. The first experiments carried out give satisfying 
results. But they also confirm that a great volume of data is necessary in order to 
extract a large quantity of lexical knowledge by the analysis of syntactic distributions. 
Moreover the very low recall of the syntactic parser and its systematic errors on some 
constructions, for example the passive form, which is very common in the journalistic 
style of our corpus, reduce the number and size of the classes. To solve this problem, 
we envisage trying another analyzer or adding a post-processing step to Sylex that 
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detects the passive form by using data already in its output. These adaptations and the 
study of larger corpora will allow us to obtain a good coverage of numerous semantic 
domains. So, we will be able to give valuable semantic data useful in a lot of 
applications as information retrieval systems or word sense disambiguation systems. 
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Abstract. The goal of conceptual clustering is to build a set of embedded 
classes, which cluster objects based on their similarities. Knowledge organiza- 
tion aims at generating the set of most specific classes: the Generalization 
Space. It has applications in the field of data mining, knowledge indexation or 
knowledge acquisition. Efficient algorithms have been proposed for data de- 
scribed in <attribute, value> pairs formalism and for taking into account domain 
knowledge. Our research focuses on the organization of relational knowledge 
represented using conceptual graphs. In order to avoid the combinatorial explo- 
sion due to the relations in the building of the Generalization Space, we pro- 
gressively introduce the complexity of the relations. The KIDS algorithm is 
based upon an iterative data reformulation which allows us to use an efficient 
propositional knowledge organization algorithm. Experiments show that the 
KIDS algorithm builds an organization of relational concepts but remains with a 
complexity that grows linearly with the number of considered objects. 



1 Introduction 

In Artificial Intelligence, the problem of the automatic construction of classifications 
has been the subject of much researches during the last fifteen years [6], [8], [13]. It 
consists in searching for similarities between objects which are not pre-classified and 
structuring them in a hierarchy of classes in which similar objects are clustered. A 
class is also called a concept since it is described by an extension (the set of objects 
clustered) and by an intension (the similarities of the descriptions of the objects clus- 
tered). Most of the existing Conceptual Clustering approaches defined this task as the 
search for a classification that would best predict unknown features of new objects 
[5], [7], [8]. This type of construction is guided by heuristics, which allow one to 
choose the best classes among the possible ones. The developed methods have proved 
their interest in various fields [6], [8], [9], [13]. In other words, the classifications 
built do not contain a class for each subset of objects whose descriptions have simi- 
larities. More recent researches concern the construction of classifications that or- 
ganize knowledge [3], [15]. In these tasks, the goal is not to build a subset of the pos- 
sible classes but all the classes clustering similar objects: the Generalization Space. In 
these methods, the process of construction is not based on a numerical distance 
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among descriptions and on a function to be optimized but on a language to describe 
the similarities among the object descriptions. This language is called the generaliza- 
tion language. 

Efficient algorithms have been proposed for organizing data described by a set of 
pairs <attribute, value> [15] and for taking into account domain knowledge [1], [3], 
Our research concerns organization of relational data, i.e. data represented in more 
expressive formalisms (first-order logic, description logic, conceptual graphs ...). To 
avoid the problem of combinative explosion due to graph matching, we propose to 
take gradually the complexity of graphs into account through a hierarchy of abstrac- 
tion spaces. The proposed approach, called KIDS, extends the propositional approach 
of knowledge organization GOING [1] to the relational framework. Given a set of 
objects described using conceptual graphs [17] and domain knowledge represented in 
a generalization lattice [14], GOING builds the Generalization Space of propositional 
descriptions of the objects. KIDS gradually enriches this space thanks to a generaliza- 
tion language which is made more and more expressive at each step of the algorithm. 
This idea, inspired from the REMO system [19], consists in increasing gradually the 
structure of matching. The KIDS algorithm is based upon an iterative reformulation of 
the data, which allows us to use GOING on the reformulated descriptions of the ob- 
jects. 

In the next section, we present the GOING propositional algorithm for knowledge 
organization. Although GOING is based upon relational descriptions of data, it does 
not use the structure of the descriptions in the construction of the Generalization 
Space. Section 3 introduces the KIDS approach: we describe our method for graph 
reformulation by abstraction, present the KIDS algorithm and illustrate our approach 
on an example. In the next section, we evaluate KIDS on a Ghinese characters data- 
base. These experiments show the feasibility of the proposed approach. Finally, in 
section 5, we conclude with a brief summary and outline directions for future re- 
search. 



2 Organization of Relational Knowledge 



2.1 A Graphical Representation of Relational Data and Their Generalization 

In the automatic construction of classifications, choosing the right language for repre- 
senting the objects is very important; it has an impact on the efficiency of the algo- 
rithms manipulating them. The more expressive a language is, the more complex are 
the algorithms manipulating it. Objects are structured, and this is true in many fields; 
they may be decomposed into several parts, and these are then linked together thanks 
to various relations (for example a part-of relation). Attribute-value languages do not 
allow to easily represent such structure. We use a language based on a higher-order 
logic and represent relational descriptions of objects in the conceptual graphs formal- 
ism. However, this representation is not a limitation of our approach, as it may be 
applied to any relational data described by graphs. 

A conceptual arc is a triplet: [concepts] -> (relation) -> [concept J , 
where (relation) corresponds to a relation between [concepts] and [con- 
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ceptdJ . A conceptual graph is a graph composed of a set of conceptual arcs. For 
more information about conceptual graphs, the reader should refer to [19] [4], 

Figure 1 below presents an example of a house description using conceptual 
graphs. The triplet [Window] -> (color) -> [White] is a conceptual arc. 
This example is used throughout the article to illustrate the algorithms presented. 





Fig. 1. A house and its description as a conceptual graph. 



2.2 Organizing Knowledge in a Generalization Space 

Given a set of object descriptions and a generalization language, the associated Gen- 
eralization Space (GS) is the set of the most specific conjunctive concepts generaliz- 
ing these descriptions. In the GS, a node is a pair (c„ d). The element c„ called the 
coverage of is the set of objects covered by and d^, called the description of n, 
corresponds to the common features (most specific generalization) of the objects of c,. 
In the GS, a node corresponds to a cluster of objects described in intension by its 
description d, and in extension by its coverage c,. Nodes of GS are partially ordered by 
a subsumption relation between concepts. Given a node n with coverage c„ its ances- 
tors are all the nodes n^, such that Cj to C,. This partial order provided the GS with a 
pruned lattice structure^, which may be represented by an inheritanee network. In- 
deed, GS nodes inherit the descriptions of the nodes which are more general. 

Figures 4 and 9 present two different Generalization Spaces of the same objects (as 
explained in the next section, part of their node descriptions come from the use of a 
generalization lattice over the types). Their differences lie in the expressiveness of the 
generalization language used to build the GS. In effect, given a set of object descrip- 
tions, depending on the language chosen to describe the generalizations (the node 
descriptions), the nodes of the associated GS will not be the same. The node n’3 in the 
GS of figure 9 for example does not appear in the GS of figure 4. Moreover, for a 
given set of objects, nodes belonging to different GS but having the same coverage 
may have a more or less general description. The node n’2 in the GS of figure 9 and 
the node n2 in figure 4 have the same coverage on objects ({h2, h3}) but the descrip- 
tion of the node n’2 is more specific than that of n2. 



’ The Generalization Space may also be defined by the two isomorphic lattices: the Galois 
lattice of concept descriptions (partially ordered by the subsumption relation) and the lattice 
of objects (partially ordered by the inclusion relation) [12]. 
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2.3 A Classical Simplification of the Graph Generalization Problem 

To avoid the exhaustive analysis of each of the 2” partitions of n objects, GOING 
adopts a bottom up approach generalizing objects descriptions to incrementally build 
the GS. In GOING, objects are represented using conceptual graphs. In order to deal 
with the problem of matching graphs which is known to be NP-complete, GOING 
transforms the graph representation into an arc representation. In other words, each 
graph describing an object is transformed into a set of independent arcs. This 
reformulation has the advantage to limit the complexity of the algorithm (in the worst 
case quadratic with the number of objects [1]) because, as the arcs are oriented they 
fully match. However, this restricts the generalization language since relations among 
arcs are not considered. 

The GOING principle for building the GS is as follows: 

1. Reformulate each graph describing the objects to be organized as a set of 
arcs. 

2. Generalize each arc describing the objects. GOING integrates an efficient 
method for taking into account domain knowledge in the GS construction 
[1]. This knowledge, represented in a generalization hierarchy (called the 
“type lattice” in the conceptual graphs formalism [17]) expresses, for exam- 
ple in the domain of colors, that the type Black and White (noted B&W) 
is a generalization of the three types White, Black and Gray. Figure 2 
below presents part of the concept type lattice used for the houses. 

Tc 

Opening 

Door Window 



Fig. 2. Part of the concept type lattice used for the houses. 

3. Group the generalized arcs and initial arcs covering the same set of objects. 
For example, the arc [Window] -> (color) -> [B&W] is a generalization 
of the two arcs (thanks to the type lattice above on figure 2): [Window] - 

> (color) -> [Gray] and [Window] -> (color) -> [White] . This 
arc will be part of the description of the node covering objects described by 
one of these arcs. 

4. Filter the generalized arcs. Indeed, for a given matching there are several 
possible generalizations. For example, the two arcs [Window] - 

> (color) -> [B&W] and [Window] -> (color) -> [Colour] are both 

generalization of the arcs: [Window] -> (color) -> [White] and 

[Window] -> (color) -> [Gray] . This step considers each set of arcs 
for a node and chooses the arcs that will form the description of this node in 
the GS. In constructing the GS, the number of generalizations is limited 
while considering only the most specific ones. The filtering step thus consists 
in memorizing only the most specific arcs (on the example above, the arc 
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[Window] -> (color) -> [B&W] ). As GOING is using a propositional 
language, the most specific generalization is unique. 

5. Finally, the nodes are connected thanks to the inclusion relation existing 
among their coverage. 

Figure 3 summarizes the principle of the GS construction. 




Reformulation 

of graphs into a set 
of arcs 



Elementaryarcs 




Generalize 



Elementary and 
generalized arcs 



(Type hierarchy) 



Conceptual graphs 
[Sowa 84] 



arcs 



Generalization Space 




Link clusters 



01 02 03 04 



^ Group 

dusters of arcs 
H' Filter arcs 
dusters of maximally specif icarcs 



Fig. 3. Principle of the construction of the most specific Generalization Space. 

In order to illustrate the GOING approach, let us consider the three houses hi, h2 
and h3 whose descriptions need to be clustered. These houses are described by their 
windows which have two proprieties: a color and a size. Figure 4 below presents 
the GS build by GOING for these houses. 

This Generalization Space contains two class nodes (nl and n2) and three object 
nodes corresponding to the houses (box nodes). The node n2, for example, clusters 
the houses h2 and h3. Its coverage is {h2, h3} and its description is the arc [Win- 
dow] - > (color) - > [Gray] . This class node indicates that h2 and h3 have at least 
a gray window in common in their descriptions and that this property is not shared 
by any other object considered. Thanks to the structure of the GS, we may add the 
description of the root node (nl) to this description. More precisely, we add the arcs 
from nl which are not generalizations of arcs from n2, for example the arc [Win- 
dow] - > (Size) - > [Big] . Finally, the GS indicates that the two houses h2 and h3 
have window (s), which have a size (Small, Big) and a color (Gray and 
Black). 

Let us clarify why the arc [Window] - > (color) - > [B&W] appears in the root 
node and why the arc [Window] - >(size)->[Size] does not. This explanation 
will clarify the 3'“* step of the GOING principle (cf previous page). 

The arc [Window] -> (color) -> [B&W] is a generalization of the arc 
[Window] -> (color) -> [Black] . As this last arc is more specific and 
since they have the same coverage on objects ({hi, h2, h3}), the arc [Win- 
dow] - > (color) - > [B&W] should not appear. However, this arc is useful 
because its coverage on arcs is bigger than that of [Window] - > (color) - 
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> [Black] : it also covers the arcs [Window] -> (color) -> [White] 
and [Window] -> (color) -> [Gray] . In fact, this arc tells us that there 
is a window whose color is [B&W] . 

Consider now the arc [Window] -> (size) -> [Size] . It is more gen- 
eral than both the arcs [Window] -> (size) -> [Small] and [Win- 
dow] -> (size) -> [Big] . The coverage on objects of these three arcs is 
the same ({hi, h2, h3}). The coverage on arcs of [Window] -> (size) - 

> [Size] is exactly the union of the coverage on the arcs of the two arcs 

[Window] -> (size) -> [Big] and [Window] -> (size) - 

> [Small] . The arc [Window] -> (size) -> [Size] is therefore not 
useful and not informative; it should not be part of the root node description. 



I House 1 1 Window 1 1 Window 1 1 Window 1 1 Window | 




I Window] I B&W j j Black j j Siiiall j j Big j 




Fig. 4. Generalization Space built by GOING. 



In order to deal with the traditional knowledge representation tradeoff [1 1] between 
an expressive language and an efficient algorithm, GOING reformulates conceptual 
graphs into conceptual arcs. This simplification supplies the GOING algorithm with a 
quadratic complexity in the number of objects, but restricts the generalization lan- 
guage, i.e. the expressiveness of the GS node descriptions. Let us illustrate this point 
using the house example. The three houses hi, h2 and h3 all have a small window and 
a black window; for hi and h2 it is the same window, whereas for h3 it is not. This 
difference does not appear in the classification built by GOING (see fig.4) since it 
requires representing relations between arcs. 
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3 Organize Knowledge in a Hierarchy of Generalization 
Abstraction Spaces 

Building an organization of relational descriptions requires to build a Generalization 
Space whose nodes use a relational representation. Given a set of objects described as 
graphs in the conceptual graph formalism, each node in the GS would ideally be rep- 
resented by the graph that is the most specific generalization of the graphs describing 
the objects it covers. Let us note this Generalization Space as GS,,,^. In fact, due to the 
complexity of the subsumption relation and the exponential growth of the length of 
the least general generalization, building GS,,,^ directly using an exhaustive method is 
not practical. The matching curse is also true for the first-order languages used in 
Inductive Logic Programming (ILP); they define syntactic restrictions on clauses to 
devise efficient ILP algorithms [16] which are similar to the restrictions on graphs 
used to devise graph-based algorithms [1], [12]. 

The solution proposed in this paper is to build an initial GS using a propositional 
language and then to iteratively enrich this GS. This enrichment consists of refining 
the descriptions of existing nodes or adding new nodes. We present in the following 
sections our approach, called KIDS, which is using GOING and relies upon the ab- 
straction of relational data. 



3.1 KIDS Principle 

KIDS is based upon the following property of the GS which allows us to limit the 
search space at each step of the algorithm: 

If there exists a sub-graph which generalizes n object descriptions, then 
there is in the GS built by GOING a node whose coverage contains these n ob- 
jects (and possibly others) and whose description contains all the arcs of the 
generalizing sub-graph 

In other words, this property of GS means that to enrich any node of a GS, it is suf- 
ficient to restrict the search for richer descriptions only to the objects it covers. This 
principle simplifies the process of enriching a GS. In effect, the nodes of GS„ (found 
by GOING) are a subset of the nodes of a GS whose generalization language is richer 
than the one used in GOING and the description of each node of GS„ is more general 
than that of GS. 

In order to find richer descriptions of GS nodes, our approach consists of gradually 
increasing the matching structure, i.e. the matching structure is made more complex at 
each step of the algorithm. At each step, the objects descriptions are reformulated 
based upon this structure into a propositional language. The reformulates descriptions 
may then be processed by the GOING algorithm. 

More precisely, KIDS uses sub-graphs to represent the relational nature of the de- 
scriptions. In order to reformulate these sub-graphs into a propositional language that 
may be performed by GOING we make an abstraction. This abstraction transforms 
the sub-graphs representation into a representation appropriate to GOING : a structure 
like [concept-type] -> (relation-type) -> [concept-type] . In fact, the rela- 
tion-type is replaced by an “ abstract relation ” representing the matching structure. 
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For example, at the F‘ level of KIDS (first step of the algorithm), an arc performed by 
GOING is: 

[House] p> (has) [Window] (size) [Small] 

The triplet (has) -> [Window] -> (size), which is in the box, is an abstract relation. 
Figure 5 below presents the general KIDS principle. 




Fig. 5. Principle of KIDS. 



3.2 Towards a New Generalization Language 

To enrich at each step the matching structure is equivalent to modify at each step the 
generalization language. KIDS starts with a language of arcs (provided by GOING), 
then it uses at the first step a language of couples of connected arcs, then at the second 
step a language of triplets of connected arcs, etc.. These successive generalization 
languages are expressed according to particular connected sub-graphs: sequence, star 
and hole structures. 



Definition 1: A sequence is composed of a succession of arcs, which are connected 
one-to-another thanks to a common concept. This concept is the origin of the first arc 
and the target of the other one. 



Small 



Fig. 6. Example of a sequence-stmcture composed of two arcs through the common concept of 
Window 
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Definition 2: A star is composed of a set of conceptual arcs which have the same 
origin. 



Window 




Window 



Fig. 7. Example of a star-structure composed of two arcs through the concept of House 

Definition 3: A hole-structure is composed of a set of conceptual arcs which have the 
same target. 



Door 



Window 



Fig. 8. Example of a hole- structure composed of two arcs 

The number of arcs of an abstract relation depends on the level of KIDS (the step 
of the algorithm): two connected arcs at the 1“ level, 3 at the 2”“' level, ..., i+1 arcs at 
the i* level. The more the sub-graph structure is complex, the more the matching for 
the reformulation is expensive. Nevertheless, the specific structure of the GS and the 
iterative method of KIDS allow us to limit the number of nodes to explore at each 
step. 



3.3 KIDS Algorithm 

The principle of the KIDS algorithm is to explore, at the f step, only the nodes which 
may be enriched, i.e. the nodes whose descriptions potentially contain an i"’ level 
structure. In practice, at step (i+I)*, KIDS explores all the nodes which were modified 
in step i. Indeed, an (i+l)"’ level structure is the aggregation of an i* structure and one 
arc. We define a candidate node for KIDS at step i+l a node which has been modified 
in step i. In the first step, KIDS explores all the GS nodes built by GOING. The GS 
enrichment algorithm is as follows (cf. Table 1): 

1. For each object covered by a candidate node, determine its i"* level descrip- 
tion: (i+l) connected arcs. It consists of abstracting the object descriptions 
using the three structures: sequence, star and hole. 

2. Apply GOING to the reformulated object descriptions. The result is the ad- 
dition of new nodes to the GS and/or the modification of the descriptions of 
existing GS nodes. Notice that the new descriptions found by GOING have 
to be reformulated in terms of sub-graphs. It consists of reformulating the 
descriptions using the abstract relations. 

3. If KIDS modifies the GS at the (""step, then repeat the method from I) at the 
(i+I)“’level (i+2 connected arcs). 
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Table 1: KIDS main algorithm 

KIDS_Algorithm (GS; Generalization Space; 1: level) 

GS_modified <— false 

Nodes_List list of GS candidate nodes 
for all the nodes n of Nodes_ List do 

Objects_ List ^ Description of n's objects at the 1*^*' level 
GS_enriched COING_Algorithm (Ob j ects _List) 

if GS_enriched modified then GS_modified true 
GS <— Add (GS_enriched, GS) 
end for 

if GS_modified == true then KIDS_ Algorithm (GS , 1+1 ) 



While the complexity of the matching for generalization is avoided by the use of 
abstract relations, the complexity of graph matching is not suppressed; it is instead 
moved to the reformulation of the descriptions. In fact, the more complex the abstract 
relations are (the higher the KIDS level), the more complex the reformulation is. Nev- 
ertheless, the OS’s specific structure and KlDS’s iterative method allow us to limit the 
number of nodes to be explored at each step, while exploring only the ones that can be 
enriched. 

However, in order to find all the structural similarities among the descriptions, 
KIDS needs to be applied up to the level of structure of the maximum level in the 
objects descriptions. In other words, if there are at least two descriptions including a 
structure of level 1, KIDS will have to be applied up to the 1 level to assure a search 
for all the similarities. 

KIDS stops either when there is no more candidates node, or when it is not possi- 
ble to describe the objects at the next level (there is no structures of (i+2) arcs in the 
descriptions). Experimentally, the time needed to apply the algorithm at the next level 
may be evaluated from the time needed to build the GS at the previous level. It is 
possible to approximate the time required for the next level and to stop KIDS if this 
time is too long. Experiments in section 5 show that in our particular domain, the 
increase of time required between two successive levels is linear. 



3.4 Organizing Relational Data with KIDS 

Let us consider again the example of the houses presented in section 2.2 (figure 4) to 
illustrate KIDS improvement over GOING. Figure 9 below presents the enriched GS 
obtained by KIDS at the E‘ level ; the information drawn in black is the result of 
KIDS and in gray those of GOING. 
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Fig. 9. Generalization Space enriched by KIDS 

The abstraction allows us to discover common substructures between the objects 
descriptions. At the T' level, KIDS finds structural descriptions which were not find 
by GOING. For example, GOING did not find that all the houses have (at least) two 
windows and that all these windows have a color (W&B or Black) and a size (un- 
known, Small or Big). Furthermore, GOING did not find a class clustering hi and 
h2 and only these two houses whereas they have a small black window in common 
and this window does not appear in the description of h3 (even if h3 has a small win- 
dow and a black window but it is not the same window). This similarity is found by 
KIDS at the F' level, because it is a particular composition of two arcs. On this exam- 
ple, KIDS enriched the description of existing nodes and added a new node clustering 
hi and h2. From a GS built using a propositional language, KIDS has allowed to give 
more precise descriptions on the existing similarities between the objects thanks to an 
abstraction of sub-graphs. 

On this example, it is useless to apply KIDS at the 2”“* level. Indeed, the stars and 
sequences of hi, h2 and h3 descriptions are of l“ level, i.e. they connect 2 arcs. Once 
the descriptions are reformulated using F‘ level structures, there is only one way to 
rebuild the description; the reformulation using first level structures is not ambiguous, 
nor losses information. Figure 10 illustrates this idea. 
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Fig. 10. Rebuilding a graph from its decomposition in structures. 



4 Experiments 

This section presents an application of the above method in the framework of the 
construction of a classification of Chinese characters. We briefly remind the context 
of this work. For more information about this application, the reader should refer to 
[2]. These experiments aim to show the feasibility of KIDS in terms of complexity 
and to illustrate its interest for relational data organization. 



4.1 Description of the Relational Data 

The database considered is a collection of 6780 Chinese characters. Each character is 
represented by a conceptual graph. Characters are described by : their initial and final 
pronunciation, the ton of this pronunciation, the components (between 1 and 5) and 

I hi 

their relative positions and the key component. For example, the character I ^ , which 
is composed of the radicals C5381 and C2843, which is pronounced “ qing ”, which is 
in ton 2 and means "feeling", is represented by the conceptual graph of figure 11. 



[ton2] 



"feeling" 



[q] (followed) 

/ 

(tone) (pronunciation) (key) 

, (means) [c2^2] 



[high] ' 



[ing] 



(frequency) 




(composed) 

(composed) 
(nbcomponents ) 

\ 

[2] 



(sameini) 

(samefin) 

(sameton) 

(position) 



(leftto) 



lc2843] (position) 
(sameini) 
(sametin) 
\ (sameton) 



[false] 

[false] 

[false] 

[left] 



[right] 

[true] 

[true] 

[true] 



Fig. 11. Conceptual graph describing the character 
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The type lattices used for the Chinese characters are the following : 

final ^mundation initial pronunciation 

composed-voyel 



■ ’ nosed-vovel 

/A 

in_n in_ng 

/X-. 

an en ang ing 



in o in_e 



palatal dental labial 

A 



1 q 



followed position tone pronunciation composed means 

Fig. 12. Part of the type lattices for the Chinese characters. 



4.2 Results and Discussion 

We evaluated KIDS on several databases of characters composed of 10 to 140 or 416 
characters. Figure 13 shows the total time required for generating the GS for 8 of 
these databases using the GOING and the KIDS algorithms. 




0 20 40 60 80 100 120 140 160 180 

Number of Chinese characters 



—♦—GOING 
-■—KIDS 1st level 
KIDS 2nd level 



KIDS 3rd level 
KIDS 4th level 



Fig. 13. Average execution time of GOING and KIDS on Chinese characters databases. 

In practice, the CPU time of the proposed algorithms is linear (it is quadratic in the 
worst case in GOING [1]) with the number of objects. This results may surprise be- 
cause, as it manipulates sub-graphs, KIDS introduces a complexity factor. However, 
the combinatorial explosion due to the generalization of sub-graphs is limited since 
the bigger the level of KIDS is (i.e. the more complex are the graphs to generalize) 
the less the number of sub-graphs to perform is. 

The level introduces a multiplicative factor. The linear growth means that on the 
average, the time necessary to move to the next level is very close to be constant. 
Figure 14 illustrates this result. 
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Level of the algorithms used 



Fig. 14. Evolution of the multiplicative factor as a function of the algorithms used. 

During these experiments, we also evaluated the evolution of the number of nodes 
of the GS as a function of the algorithms used. For GOING, this number is in the 
worst case in 0(N) [1]. Figure 15 summarizes these results. 




Fig. 15. Evolution of the number of nodes of the GS. 

This graph shows that the number of nodes of the GS grows until a specific level - 
F‘ level for the small bases and Z””* level for largest - then it becomes constant. This 
may be explained by the fact that from a specific level, KIDS does not allow to create 
new classes, but only to enrich the already existing ones with more complex descrip- 
tions. 



5 Conclusion 

We have presented KIDS, an algorithm for organization of relational data. This algo- 
rithm is iterative and is based upon an abstraction of the description. In a first step, it 
builds the space of the most specific generalizations using a propositional language. 
Then it uses reformulation to find more complex descriptions. We have implemented 
and successfully tested our approach. Our experiments suggest that the proposed 
method provides an organization of relational concepts while keeping a linear com- 
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plexity in practice with the number of objects. This result is due to the fact that the 
more complex are the structure, the less are the nodes to explore. 

The first perspective of this work is to characterize more precisely the generalized 
language used in the enriched GS. Indeed, as soon as we work on the o-level struc- 
tures, there is no longer a unique most specific generalization and GS nodes may be 
redundant. The characterization of the enriched language of GS allows us to evaluate 
the usefulness of the sub-graphs and to filter them in order to keep the useful one. 

Another possible improvement of the algorithm is to define methods to evaluate 
the interest of KIDS for a given database. Indeed, when the concepts in the objects of 
a conceptual graphs database appear only once, it is not necessary to apply KIDS to 
this database, because the decomposition does not cause a loss of information. In 
contrast, if a concept appears several times in the objects descriptions (like in the 
houses), it is not possible to differentiate them. So, we can consider a pre-processing 
on the data to evaluate the maximal level of KIDS application. 

Finally, we plan to extend this method for a more efficient processing of numerical 
data. Currently, the numerical information contained in descriptions is processed like 
symbols ; the implicit order existing between numbers is not taken into account. A 
preprocessing on descriptions would make it possible to determine a hierarchy of 
generalization of the numerical values. The creation of new values of attributes, as it 
is the case in constructive induction, would make it possible to better account for the 
similarities between descriptions [10], [18]. 
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Abstract. Knowledge refinement tools rely on a representative set of 
training examples to identify and repair faults in a knowledge based sy- 
stem (KBS). In real environments it is often difficult to obtain a large set 
of examples since each problem-solving task must be labelled with the 
expert’s solution. However, it is often somewhat easier to generate unla- 
belled tasks that cover the expertise of a KBS. This paper investigates 
ways to select a suitable sample from a set of unlabelled problem-solving 
tasks, so that only the subset requires to be labelled. The unlabelled 
examples are clustered according to the way they are solved by the KBS 
and selection is targeted on these clusters. Experiments in two domains 
showed that selective sampling reduced the number of training examples 
used for refinement, and hence requiring to be labelled. Moreover, this 
reduction was possible without affecting the accuracy of the final refined 
KBS. A single example selected randomly from each cluster was effec- 
tive in one domain, but the other required a more informed selection 
that takes account of potentially conflicting repairs. 



1 Introduction 

Knowledge refinement is incremental learning, where the learning must adapt 
existing knowledge in a Knowledge-Based System (KBS). Refinement tools aid 
knowledge engineers by assisting with the knowledge debugging and maintenance 
phases in the Knowledge-Based Systems development cycle [1,2,3]. These tools 
ensure that the KBS’s solution is consistent with that of a domain expert for a 
given task. In common with other learning algorithms, the tasks and the expert’s 
solutions are maintained as training examples. Refinement is triggered when the 
system’s and expert’s solution for a given task are inconsistent. Although training 
examples that indicate faults are useful to drive refinement, access to correctly 
solved training examples is beneficial, because, they help focus refinement by 
ensuring that repairs are not too closely fitted to wrongly-solved examples. 

The choice of training examples for refinement becomes important when one 
of the constraints on the refinement process is a limited number of labelled 
training examples. This is a relatively common problem in a real environment. 
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where labelling many problem-solving tasks with the expert’s solution may re- 
quire significant interaction with a busy expert. Unlabelled training examples 
are often generated by using domain knowledge already embodied in the KBS or 
meta-knowledge [4]. Therefore, unlike the labelling task, generating unlabelled 
examples does not typically require the expert. The goal of the work described 
in this paper is to perform an informed selection from a set of unlabelled trai- 
ning examples which the expert must subsequently label, thereby reducing the 
demand on the expert. However, we must ensure that the informed selection of 
relevant training examples does not hamper the refinement process by omitting 
examples that uniquely reveal faults. 

The problem of unavailability of labelled training examples and sample selec- 
tion of relevant examples from a set of unlabeled examples falls under the para- 
digm of active learning and more specifically, selective sampling. Much work has 
been done in selective sampling mainly related to training classifiers: for nearest 
neighbour, using a lookahead approach that selects examples based on statistical 
information about the utility of the resulting classifier [5] ; for text classification, 
using a committee-based approach combined with expectation maximization [6]; 
and for C4.5 using a probabilistic classifier that selects examples based on class 
uncertainty [7]. Increasingly, estimation and prediction techniques with roots 
in statistics are being applied to classifiers with improved accuracy results [8]. 
However, the use of examples for training classifiers differs from their use for 
refinement tools: 

— in refinement, examples are used to expose faults in an existing KBS and so 
are employed to refine incomplete concepts and not learn from scratch; and 

— examples are used for refining KBSs that model, not only classification tasks 
but also design tasks [9] and even planning tasks [10]. 

Direct application of currently available selective sampling methods for lear- 
ning classifiers to refinement tools is therefore, not straightforward. We adopt 
the common approach of partitioning the available examples into clusters, but 
exploit the relationship between the examples and how they are solved by the 
faulty KBS, in contrast to existing selection techniques that exploit the stati- 
stical distribution of examples. As a result our clusters will contain examples 
that trigger similar problem solving behaviour in the KBS. We then apply va- 
rious heuristics that help select examples from clusters. However, the presence 
of interacting faults in a KBS complicates sample selection since they require 
the selection of more than one example from each cluster. We have developed 
heuristics that identify those examples that are most likely to demonstrate inter- 
acting faults and we propose algorithms that apply these heuristics to example 
selection. The selected subset of examples is then presented to the expert for 
labelling. Once labelled, these examples can be used by the refinement tool to 
drive the refinement process. 

Section 2 introduces iterative refinement by describing the process underta- 
ken by a particular family of refinement tools. The selective sampling process in 
Section 3, firstly, describes a structure that captures problem-solving behaviour 
of the KBS for a given task, secondly, presents a clustering framework that uses 
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this problem-solving behaviour to determine similarity between unlabelled ex- 
amples, and thirdly, identifies several heuristies for selecting a suitable number of 
examples from these clusters. Experimental results from evaluating the selection 
heuristies on two problem domains which have different problem-solving charac- 
teristics is presented in Section 4. Finally, in Sections 5 and 6, we discuss related 
work in the field and conclude with contributions of tliis work and implications 
for future work. 



2 R.efinement with KRUSTtools 

The Krust Works project has developed a generic knowledge refinement fra- 
mework. Given a specific rule-base shell, this framework is u.sed to generate a 
refinement tool, a IvRUSTtool, by re-using core refinement modules. These mo- 
dules arc applied to generic knowledge structures which model the behaviour of 
the rule-base. The structures a, re formed by translators that work on the specific 
rules and the associated traces [1]. The currently developed firamework is able to 
deal with faulty KBSs implemented in shells incorporating reasoning strategics 
that can be forward-cliaining, backward-chaining or both. 




In common with many refinement tools, KrUSTIooIs incrementally refine a 
KBS based on fault evidence provided by labelled training examples. A labelled 
training example e is a task-solution pair the observables 

/ii • • • )/m the facts that initialise the problem-solving task, and its solution 
goal is the example’s la.bel acquired from the expert. The KRt.TSTtool’s refine- 
ment process is iterative with labelled training examples ei, . . . , e„, utilized one 
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at a time (Figure 1). The input KBS for each iteration is the best refined output 
KBS from the previous iteration, or the original faulty KBS in the first iteration. 
The training examples buffer contains all labelled examples that are yet to be 
used by the KRUSTtool. For each iteration, the top example in this buffer is cho- 
sen as the refinement example and drives that refinement cycle. If the refinement 
example is correctly solved by the input KBS then refinement is not required, 
otherwise the fault evidence is employed to allocate blame. The refinement al- 
gorithm then identifies various ways by which the required target solution can 
be attained and generates several potential refinements and implements them 
as refined KBSs. Once used, the refinement example is then transferred into the 
constraint examples buffer, which is simply the buffer that keeps track of ex- 
amples previously solved by the KRUSTtool. However, an important task of this 
buffer is to help filter refined KBSs, by rejecting those that incorrectly answer 
any of the examples in it. The filtered refined KBSs are then ranked by their 
accuracy on the training examples buffer, and the refined KBS with the highest 
accuracy is the output KBS for this iteration. 

Fundamental to the KRUSTtool’s successful refinement operation is the avai- 
lability of labelled examples for its buffers. Availability is often constrained by 
limited expert interaction and high processing costs. The KRUSTtool should ide- 
ally be able to handle such situations by actively selecting training examples 
from an available set of unlabelled examples. Selected examples must be bene- 
ficial for improving the effectiveness and efficiency of the refinement tool. The 
effectiveness depends on whether or not the tool has had access to examples 
that are able to expose faults; this requires a mechanism that enables selection 
of examples that trigger a wide range of faulty problem-solving behaviour in the 
KBS. Improving efficiency involves selecting fewer refinement examples, thereby 
reducing the number of refinement iterations required to achieve refined KBSs 
with improved accuracy; e.g. ensuring that only one incorrectly solved example 
from a set of examples exposing each fault is processed. 

3 Selective Sampling Process 

The relevance of training examples for refinement changes as refinement pro- 
gresses. As the problem-solving behaviour of the KBS is incrementally improved 
examples that exposed faults before are less likely to expose new faults in future 
iterations, while examples that did not before may do so in future iterations. 
Therefore we need selection mechanisms that target examples for refining the 
KBS given its current problem-solving behaviour. The use of selective sampling 
for the KRUSTtool encompasses an informed selection of examples, the labelling 
of these selected examples by the expert, and the refinement of the faulty KBS 
using the batch of labelled examples. A single iteration of this select-label-refine 
process provides a small batch of labelled examples to use as the initial training 
examples buffer for the KRUSTtool (see Figure 2). Once the KRUSTtool has in- 
crementally refined the KBS to correctly solve these labelled examples, the next 
iteration of select-label-refine can be triggered. In practice, the select-label-refine 
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Expert 




Labelled Training Examples 



Fig. 2 . A single iteration of select-label-refine. 



process must be repeated until; no further faults are exposed in the KBS hence, 
no improvement in accuracy; or a limit on the number of examples an expert is 
willing to label is reached. 



3.1 Problem-Solving Behaviour 

The KRUSTtool records the problem-solving that is undertaken by a KBS for 
an example in a structure, the positive problem graph[l]. Essentially it records 
the rule activations and the order in which these activations occur. Figure 3 , 
shows two simple positive problem graphs for a fictitious faulty KBS with ru- 
les i?4, i?5, i?7, i? 8 , -Rg among others. Let us assume that each positive problem 
graph captures the observed problem solving behaviour of the faulty KBS, as a 
result of executing each of the two unlabelled examples, A=([Ai, . . . , A4 ] , ?) and 
B=([i?i, . . . , B4] , ?). With example A, the KBS reasons from the observables by 
applying leaf rules i?7 and R4, which together allow a middle rule i?g to fire, 
and finally the conclusion of the end rule Rg provides the system solution, sysA- 
A system solution would typically be a class, a design, a formulation or a plan, 
depending on the type of problem domain. Similar explanations hold for exam- 
ple B’s positive problem graph, but notice that reasoning has not progressed 
beyond the conclusions of leaf rules, R4 and Rg. Here, we have an intermediate 
result but no obvious system solution. We shall use the similarity between the 
positive problem graphs of examples to determine which examples may indicate 
the same faults in the KBS. The task of establishing similarity in this manner 
means that we need only be interested in rule activations for examples, regardless 
of whether or not the system solution is correct. Therefore, more importantly, 
examples need not be labelled for this task. 



3.2 Cluster Formation 

To form example clusters we need to define a similarity metric which is then 
utilized by a clustering technique that progressively develops the clusters. Since 
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Fig. 3. Positive Problem Graphs for examples A and B. 



examples are presented as a vector of observables, an obvious similarity metric 
compares these vectors. However, in knowledge refinement we are interested in 
sampling examples with respect to problem-solving behaviour of the faulty KBS 
and so our similarity metric reflects this by making use of the positive problem 
graph. Given a KBS containing rules i?i, . . . , Rn, we define a binary valued rule 
vector corresponding to an example e as r = (ri, . . . , tat), where = 1 if Ri 
appears in the problem graph for e, and rj = 0 otherwise. Thus, the rule vector 
for the training example A in Figure 3 is (0, 0, 0, 1, 0, 0, 1, 1, 1, 0), where N=10. 
Here the I’s correspond to rule activations R4,R7,R8 and R9. 

The similarity measure needs to capture refinement similarity between two 
unlabelled training examples ei , 62 . As refinement similarity depends on the si- 
milarity in problem solving behaviour, the similarity between Ci, 62 , can be esta- 
blished by comparing their rule vectors ri,r 2 . For this purpose the Euclidean 
distance metric may be used, but it can lead to two rule vectors being regarded 
as highly similar despite them having no common rule activations. Association 
coefficients [ 11 ] avoid this by focusing on the common rule activations and nor- 
malizing by the number of rule activations in both rule vectors, thereby ignoring 
rules that are not activated. We employ the Dice coefficient, a commonly used 
similarity measure of this type: 

RefSimiei, 62 ) = Dice{vx,Y 2 ) = ^ ^ 

ri. ri -b r 2 . r 2 

We then use an agglomerative hierarchical clustering technique, where trai- 
ning examples with the greatest similarity are united in small clusters and these 
clusters are iteratively fused until intra-cluster similarity achieves a predetermi- 
ned threshold. The decision to fuse clusters is based on the farthest neighbour 
principle [ 12 ], where those two clusters that have the minimum distance between 
their most dissimilar cluster members are fused. Typically, this form of cluster 
fusion leads to small, tightly bound clusters, provided that the fusion threshold 
is low. 
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3.3 Selecting Examples Using Clusters 

Clusters provide information that allows a more informed choice than a random 
selection of examples. Each cluster represents the problem-solving behaviour 
pertaining to some part of the faulty KBS, because examples with similar rule 
activations are clustered together. If we happen to know which area of the KBS 
is faulty, the task of example selection is reduced to picking the cluster related to 
that area. However, in most cases the KRUSTtool has no prior knowledge about 
what parts of the KBS might be faulty, and so we need a more general selection 
technique that targets all potentially faulty parts of the KBS. 

Since each cluster contains examples which are solved in a similar way by 
the KBS, it might appear reasonable to assume that repairing a fault exposed 
by a single example from a cluster would correct the rest of the cluster. One 
selection method ClusterRep exploits this assumption by randomly selecting 
one example from each cluster. Certainly, training examples that activate several 
rules in common appear in the same cluster and typically are also similar in their 
observables. However, in some situations examples from a single cluster may not 
have similar observables, and so may contain a pair of examples where a possible 
repair for one example introduces a fault into the repaired solution for the other; 
or result in no obvious repair. Faults of this nature are termed interacting faults 
and the involved pair of examples is termed a conflict pair. 

3.4 Faults that Interact 

To demonstrate the effects of interacting faults on refinement we use 4 Clips 
rules taken from a corrupted version of a student loans adviser. Of these rules, 
two have been corrupted by adding extra conditions, highlighted in bold (see 
Figure 4). Here, R16 translates to “if a student has filed for bankruptcy and is 
enlisted then grant the student a financial deferment”, and i?19 translates to 
“if a student is disabled and has filed for bankruptcy then grant the student 
a disability deferment”. Assume that the KRUSTtool is attempting to fix these 
rules based on fault evidence provided by training example x and y in that order. 

X = ([(f iled_f or_bankruptcy idx), . . .] , (eligible_f or_def erment idx)) 

y = { [(disabled idy), . . .] , (eligible_for_def erment idy)) 

Example x concerns a student that has filed for bankruptcy and according to the 
expert should be eligible for deferment, but when reasoning with the faulty rules 
the system solution will not match that of the expert’s. Therefore, the KRUSTtool 
will attempt to refine the faulty rules by either generalising R16 or i?19, by 
deleting condition {enlist IStudenf), or {disabled IStudenf), respectively. Let 
us assume that the KRUSTtool chooses to refine by incorrectly generalising i?19 
(instead of i?16) and implements this as a new KBS. On proceeding to the 
next refinement cycle (now with new KBS) the KRUSTtool is presented with 
fault evidence from training example y, a disabled student who is eligible for 
deferment. A direct consequence of generalising i?19 is that the KRUSTtool is now 
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left with no obvious refinement that can fix the fault exposed by y. Consequently, 
it is forced to re-think its previous refinement choice of generalising R19 instead 
of R16, and so faces the prospect of re-starting refinement from a previous state. 
Notice that if i?19 and i?16 were corrupted, but had no common condition that 
matched observables from either x or y (for instance like f iled_f or_bankruptcy) 
then the faults exposed by x and y in Figure 4 would not be interacting. 



(defrule R16 

(f iled_f or_bankruptcy PStudent) (enlist ?Student) 
=> (assert (f inancial_deferment PStudent) ) ) 

(defrule R19 

(disabled PStudent) (filed_for_bankruptcy PStudent) 
=> (assert (disable_deferment PStudent) ) ) 

(defrule RIO 

(f inancial_deferment PStudent) 

=> (assert (eligible_for_def erment PStudent) ) ) 
(defrule R12 

(disable_def erment PStudent) 

=> (assert (eligible_for_def erment PStudent) ) ) 



Fig. 4. Some rules taken from a corrupted student loans advisor in Clips. 



The presence of interacting faults affects the refinement process, because sel- 
ecting a non-optimal refined KBS in a previous iteration can cause refinement 
conflicts in a subsequent iteration. Detecting and resolving these refinement con- 
flicts is important, as we have found that this improves refinement accuracy and 
guides the search for the best incremental refinements [13]. However, such con- 
flicts can only be detected subject to the availability of fault evidence provided 
by a pair of examples, a conflict pair (such as x and y above). If a cluster con- 
tains conflict pairs like these, we would want to select further examples from this 
cluster. In these situations ClusterRep is not sufficient as it randomly selects 
a single example from each cluster, thereby ignoring all other examples in that 
cluster, including conflict pairs. A mechanism is needed to identify conflict pairs 
when they occur in the same cluster so that we ensure that examples exposing 
interacting faults are chosen. This necessitates an investigation of the problem- 
solving behaviour of labelled conflict pairs that occur in the same cluster. The 
aim of such an investigation is to establish criteria that would enable the iden- 
tification and selection of conflict pairs from a cluster when still unlabelled. 

3.5 Characteristics of Conflict Pairs 

An analysis of labelled conflict pairs revealed that they tend to have overlapping 
positive problem graphs, yet the best repair choices for the pair are distinguis- 
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bed from each other. Essentially their proofs may exercise similar parts of the 
KBS but their best repair exercises separate parts. Figure 5 shows the problem- 
solving for such a pair, G={[C\, . . . ,Co\\goalc) and D=([i 4 i, . . . , Dg] \goalD)- 
The darkened arrows and bold rule names highlight the positive problem graphs 
for examples C and D; i.e. the rules that are activated by the observables for 
each example. Each has resulted in the activation of the same end rule i?3, but 
the solutions {sysc and sysu) might occur with different variable bindings. In- 
variably a pair like this, with a substantial area of the positive problem graph in 
common, will be placed in the same cluster, and easily mistaken as representing 
the same fault. 





Fig. 5. Illustrating conflict pairs. 



Figure 5 also shows all rules that might have concluded each target goal 
if they had been activated; these (non)activations form the negative problem 
graph. With example C, is only partially satisfied by i?i’s conclusion. The 
arrow from C4 is fainter to indicate that this condition in is not met by the 
observable without the condition being generalised somehow. The other possible 
route via i?4 requires both of its conditions to be generalised before being sa- 
tisfied by C5 and Cg. Possible repairs attempt to specialise rules in the positive 
problem graph and generalise those from the negative problem graph^. However, 
specialising i?2 to disallow the proof of sysc for example C may cause problems 
when generalising R-j to allow the proof of goalc, for example D, and vice versa 
with and i?g. Essentially, even though conflict pairs are clustered together, 
a repair for one example will not necessarily repair the other; i.e. their negative 
problem graphs are fairly disjoint. 



^ For a comprehensive list of KrustIooI’s specialisation and generalisation refinement 
operators see [14]. 
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3.6 Informed Selection Heuristics 



When examples are unlabelled we do not know the goals and cannot build the ne- 
gative problem graphs. Instead we identify potential conflict pairs by formulating 
an indirect estimate of how overlapping the two negative problem graphs might 
be. For this purpose we compare their observables since the (non) activations in 
the negative problem graph depend on them. 

We calculate a dissimilarity score for an example Ci=( [/(, . . . , /^] , ?), in a 
cluster (7=ei, . . . ,e„ by summing all pair-wise dissimilarities between example 
€i and the remaining examples in C. 



Dissimilarity {ei,C) = dissimilarity {ei^Cj) 

j¥=i 



dissimilarity {ci, ej) 



m 









{ 0 if x=y 

W^x — nyW if X, y are numeric facts^ 

1 otherwise 

The dissimilarity score of a cluster is the average Dissimilarity of its examples. 
There is some argument for ignoring the influence of observables that have al- 
ready resulted in activations when calculating the dissimilarity score, however, 
as the contribution towards dissimilarity from observables associated with ac- 
tivations, compared to those associated with (non) activations is negligible, we 
have opted for the simpler dissimilarity score using all observables. 

When a cluster has a high dissimilarity score there is reason to believe that 
such a cluster may contain conflict pairs, and we want to select it first for refi- 
nement. The intuition behind this is that examples clustered together based on 
similarity of the KBS’s problem solving behaviour would normally also be similar 
in their observables. If observables are dissimilar then it is likely that problem 
solving behaviour of the KBS for that cluster is faulty and would require the 
selection of more than one example to fix the faults. We propose several sam- 
ple selection heuristics that select varying numbers of examples from the cluster 
with the highest dissimilarity as follows: *Dissimilar selects all examples; K- 
Dissimilar, selects the K most dissimilar examples; and >Dissimilar selects 
examples with Dissimilarity scores above a pre-determined threshold. 

4 Experimental Evaluation 

Example selection employing ClusterRep and the Dissimilar family of selec- 
tion techniques are compared against Random, where refinement examples are 

^ A numeric fact x has a numeric component n^; e.g., age(fred, 40). '^rix — riy\\ is the 
absolute difference normalised by the range of values. 
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selected randomly. Our experiments test whether selective sampling produces 
refined KBSs with comparable accuracy but using fewer labelled examples than 
Random. Furthermore, the performance of these techniques in the presence of 
interacting and non-interacting faults is also analysed by controlled corruptions 
of the KBS. 

The data set and rule-base for the binary class student loans, and the data set 
for the multi class soybean was taken from the UCI repository [15]. The student 
loans data set consisted of 1000 labelled examples. We heavily corrupted the 
student loans KBS to encourage conflict pairs; by introducing 5 faults to the 
20 rules. The soybean data set of 337 labelled examples was formed by merging 
the large and small soybean data sets and selecting those examples classified in 
the first 15 classes. A soybean KBS with 44 rules was created by incorporating 
rule chaining into the rule set generated by c4.5rules [16]. This KBS was then 
corrupted in 7 places, by adding and modifying antecedents in rules covering 
4 of the 15 classes. Unlike the student loans corruptions, these faults did not 
interact, therefore examples from different classes have distinct problem graphs. 

For each domain, a set of 100 training examples and a further 100 evaluation 
examples are randomly selected from the data set. The KRUSTtool is run with 
increasing subsets of the 100 training examples. Although all examples in the 
data set are labelled for experimentation purposes, these labels are ignored until 
examples are selected from the training set for the refinement task. Therefore, 
the labelling step in the select-label-refine iterative process is implicit, and the 
stop criterion is that the refined KBS has 100% accuracy on the training ex- 
amples after the refinement step. We note that in practice this criterion is not 
available, as only selected training examples will be labelled, but that refine- 
ment is a continuous process constrained by expert availability. The impact of 
informed selection on efficiency is determined by the percentage of unused (un- 
selected) examples in the training set. The impact on effectiveness is determined 
by the accuracy of the final KBS on the evaluation set. The graphs show results 
averaged over 10 runs for each training set size. Significance results are based on 
a 95% confidence level and apply the Kruskal Wallis [17] non-parametric test as 
some results are not normally distributed. The optimum cluster fusion threshold 
and the Dissimilarity threshold for >Dissimilar, with each test domain was 
ascertained by experimenting with varying thresholds, on a separate subset of 
examples. 

4.1 Student Loans Domain 

Experiments indicate that informed selection methods were effective: there was 
no significant difference in final refined KBS accuracy on the evaluation set, 
between these methods and Random. Figure 6 shows the graph for unused per- 
centage of examples for each of the methods. We found a significant difference 
between these selection methods for unused percentage (p=0.005). 3-Dissimilar 
overall has faired best, and on average is three times more efficient than Random 
or ClusterRep. 3-Dissimilar and >Dissimilar have significantly higher un- 
used percentages compared to *Dissimilar, suggesting that the subset of most 
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dissimilar examples from the cluster effectively targets the faults highlighted 
by all the examples in the cluster. All Dissimilar methods use significantly 
fewer training examples compared to ClusterRep and Random. Cluster- 
Rep’s poor performance is due to the added complication of interacting faults, 
and shows that selection of cluster representatives, alone, is not sufficient in these 
situations. The increase in unused percentage with training set size 10, seen with 
all methods, is explained by small training sets being insufficient to expose all 
faults in the KBS. As a result 100% accuracy on the training set is achieved 
easily, while the accuracy on the evaluation set will be significantly worse when 
compared to refined KBSs produced from larger training sets. 
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Fig. 6. Unused examples for student loans domain. 



4.2 Soybean Disease Domain 

Again there was no significant difference in accuracy between the selective me- 
thods and Random; while there was a significant difference in unused percen- 
tages (p=0.005). From the efficiency view, in this domain, ClusterRep, uses 
significantly fewer examples than *Dissimilar and Random (see Figure 7). 
The success of ClusterRep and the failure of ^Dissimilar is explained by the 
absence of interacting faults in this rule base. Furthermore, the performance of 
ClusterRep improves with increased training set sizes, indicating that it was 
able to target few, yet good, examples. Closer examination of test runs with set 
sizes 70, 80, 90 and 100, revealed that the number of clusters tends to be con- 
stant while the size of clusters increases with the increasing number of examples, 
therefore, ClusterRep selects the same number of examples regardless of the 
increase in set size. On average ClusterRep is three-times more efficient than 
Random or *Dissimilar. *Dissimilar’s bad performance with larger training 
set sizes clearly shows that the absence of an appropriate selection mechanism 
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can result in ultimately using all the unlabelled examples. We have not plotted 
results for 3-Dissimilar and >Dissimilar methods as they are derivatives of 
*Dissimilar, which has performed poorly. 
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Fig. 7. Unused examples for soybean disease domain. 



5 Related Work 

The batch version of the refinement tool Either also applies incremental lear- 
ning [18]. It processes batches of examples as they become available, but these 
examples are not selected for a purpose. Eventually Either uses all the exam- 
ples, and in addition all these examples must be labelled. The use of membership 
queries and equivalence queries to select examples for learning Horn clauses is 
presented in [19]. Querying in this manner enables Horn clause learning in po- 
lynomial time. However, there is the assumption that labels of examples are 
known, and more importantly the logic based approach does not adapt well to 
rule-based systems that have more complex knowledge representation forma- 
lisms. Expo [10] uses selective sampling to filter its proposed plans when the 
expected outcome of the plan differs from the actual observations. Interestingly 
Expo’s active selection occurs at plan filtering, analogous to the KRUSTtool’s 
filtering of refined KBSs, and not for actively selecting planning tasks that may 
trigger learning, hence improving plan formation. This difference with knowledge 
refinement is possibly explained by the high costs associated with experimenta- 
tion compared to access to representative planning problems. 

Selective sampling employing a neural network for the task of learning a 
binary concept is discussed in [20] . An example is selected when the most speci- 
fic and most general network configurations fail to agree on the example’s label. 
With complex concepts the most general network configuration may contain the 
entire domain, thereby forcing random sampling. Our clustering has similar pro- 
blems: when the cluster threshold is too high, clusters contain single examples; 
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when set too low one large cluster contains all examples. With each extreme 
selective sampling is reduced to Random. Presently, we identify the optimum 
threshold by experimentation, however, the ability to automatically learn this 
threshold would be beneficial. 

Argamon-Engelson and Dagan in [21] use a query by committee approach to 
selectively sample training examples for a probabilistic classifier. A committee of 
classifiers is randomly drawn based on statistics of the labelled sample. Examples 
are selected according to the degree of disagreement in class labels between 
the committee members. The committee approach can also be incorporated in 
knowledge refinement where the generated refined KBSs can vote on the solution 
for remaining training examples and select examples where the committee was 
unable to reach consensus. However, a disagreement measure is complicated 
when the KBS concludes in intermediate results. 

Conceptual clustering involves arranging objects into clusters which would 
then represent certain conceptual classes [22]. However, such techniques require 
that there is some knowledge about the number of classes or, alternatively, kno- 
wledge about the goals of the classification. Usually, with knowledge refinement, 
there is no prior knowledge about the number of areas of the KBS that are faulty 
much less the types of faults that need to be addressed. However, our example 
clustering via rule vectors draws close parallels to classical document clustering 
in information retrieval where documents are represented as binary term vectors 
[23] . For information retrieval purposes documents with similar term vectors are 
grouped together forming a cluster. In document clustering, weights may also 
be used to indicate the relative importance of terms. We currently assign equal 
importance to all rule activations. However, a conservative view prefers refine- 
ments to rules closer to observables and this might be captured by introducing 
weights to rule activations. 



6 Conclusion 

We have presented an initial approach to selective sampling of training examples 
in the context of knowledge refinement. Experimental results show that selective 
sampling can significantly reduce the number of examples utilised, without any 
penalty on final accuracy. The refinement process was able to target particular 
faults that improved the accuracy of the refined KBS in a way that was effective 
in general. Not only did this reduce the number of refinement cycles required to 
achieve a particular level of competence, but it also reduced the demands on the 
expert’s time. The selection was done based on features of the problem-solving 
task alone and so the expert was consulted about only the selected examples. 
Once labelled, the selected examples were presented to the refinement tool for 
processing. 

The rule vector representation of the positive problem graph provided a sim- 
ple similarity measure that created clusters of examples that had been solved by 
the KBS in a similar way. This clustering was helpful in determining examples 
that might indicate the same repair. Future work will analyse the implications 
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of rule depth and the sequence of rule activations on similarity and investigate 
how the similarity measure might be extended to reflect these. Given a cluste- 
ring, incremental refinement can be visualised by capturing changes in cluster 
size and cluster membership. We are currently exploiting these dynamic chan- 
ges for example selection during the refinement filtering stage, where the aim is 
to identify examples affected by the proposed refinements. We note that this is 
possible due to our clustering using similarity between, rule vectors rather than 
feature vectors, as employed by most existing active learning methods. 

The difficulty of selecting examples from clusters depends on the level of in- 
teraction of the faults in the KBS. Experiments have highlighted the strengths 
of Dissimilar heuristics in the presence of interacting faults and the less infor- 
med ClusterRep selection heuristic in the presence of non interacting faults. 
We intend to develop more powerful selection mechanisms that combine these 
techniques. One possibility would be to choose between selection heuristics Clu- 
sterRep and a Dissimilar method after a clustering has been done: if the ma- 
ximum intra cluster dissimilarity is large then a Dissimilar method is required; 
if small then ClusterRep is sufficient. 

Selective sampling is important for knowledge refinement tools whether or 
not labelled training examples are plentiful. If labels are hard to obtain then it is 
certainly useful to identify relevant problem-solving tasks that should be labelled 
by the expert and then used as training examples for refinement. Conversely if 
there are many labelled training examples then, given that the refinement process 
is quite computationally expensive, it is convenient to target those examples 
whose repairs also fix other wrongly solved examples without further refinement, 
thereby reducing the number of refinement cycles. Selective sampling addresses 
both these issues by identifying the examples most likely to solve others that 
indicate the same general fault. 
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Abstract. Knowledge refinement tools seek to correct faulty knowledge 
based systems (KBSs). Most current refinement systems are applicable 
only to a single KBS shell, and typically they ignore the procedural 
aspects of KBS reasoning. This paper describes the KauSTWorks frame- 
work which refines a number of different shells, and can be extended to 
new ones. Internal knowledge structures represent rules in the target KBS 
and their interactions, and generic tools manipulate these structures. In 
this paper KRUSxWorks is evaluated on two aero-space applications into 
which various artificial faults have been introduced. KauSTWorks iden- 
tifies and fixes these faults, except when the training examples provide 
insufficient fault evidence. The evaluation demonstrates the effectiveness 
of KauSTWorks as a refinement tool, and confirms that it can represent 
the knowledge and problem-solving in real expert systems. 



1 Introduction 

Knowledge refinement tools assist in the detection and removal of faults while 
KBSs are being developed, and in the updating of KBSs whose requirements and 
specifications change over time. Most current refinement systems are somewhat 
limited in their applicability, refining KBSs written in a single language or shell, 
and ignoring procedural features such as rule precedence and conflict resolution 
strategies. In contrast, the KauSTWorks framework refines KBSs written in a 
number of different shells, and can be extended to new shells. Moreover, it repre- 
sents and reasons about non-logical features of rule execution. It does so by using 
a set of generic KBS concepts and refinement steps to represent the knowledge 
and reasoning processes in a variety of KBSs. It has already been shown that 
KauSTWorks can represent the knowledge and reasoning processes of different 
applications [1,2]. In this paper, we describe briefly the KauSTWorks system 
and its knowledge representation, and then present the results of an evaluation 
of KauSTWorks as applied to two industrial KBSs. 

Section 2 presents the KauSTWorks framework as a set of core refinement 
techniques, together with a set of toolkits. Section 2.1 describes the knowledge 
used by KauSTTools to represent the knowledge in a KBS’s rules. Section 2.2 
describes the knowledge used to represent the reasoning behaviour of the KBS, 
which in turn guides the refinement process. Section 3 describes the evaluation 
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of KRUSTWorks using two aero-space applications. Finally, we explore related 
work and offer our conclusions. 

2 The KRUSTWorks Framework 

KRUSTWorks is divided into two parts: a set of core KBS-independent refine- 
ment routines, and a set of toolkits, such as refinement operators and filters, 
from which the user selects tools appropriate for a particular application. Here 
we concentrate on the refinement routines. KrustTooIs apply the standard re- 
finement steps of running the KBS on a particular training example, allocating 
blame to potentially faulty rules and then proposing repairs that prevent the 
faulty behaviour (Figure 1). However, KrustTooIs are unusual in generating 
many repairs and using further training examples to select the best. If several 
wrongly-solved examples are available, these are used one at a time to drive 
refinement. Once processed, each example is added to a constraint buffer, where 
it is used to filter subsequent refined KBs. 




Knowledge Element 




Ordered Term AV Tuple 



Fig. 1. Iterative refinement by a Fig. 2. Part of the Knowledge Tree 

KrustTooI 



KRUSTWorks uses a common core of refinement procedures applicable to all 
the KBSs that it refines. It has been possible to create such core procedures 
because KRUSTWorks represents the knowledge of a KBS in a generic manner, 
independent of the particular rule language and development environment. This 
knowledge is divided into two parts: the static knowledge contained in the rules, 
and a dynamic representation of the ways in which the rules fire for a particular 
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training example. The static knowledge in the rules is known as the knowledge 
skeleton] it forms Krust Works’ internal representation of a KBS’s rule-base [2]. 
The dynamic knowledge represents which rules fired, in what order, and how the 
rules chained [3]. It is known as the problem graph, and is a generalised form of 
proof tree. 



2.1 The Knowledge Skeleton 

The knowledge skeleton uses a common knowledge representation language 
(CKRL) [2] to represent the important features in a KB. The CKRL has allowed 
us to implement a generic set of refinement operators which each KrustTooI 
uses to modify the knowledge in the skeleton and so correct faults in the KB. 
The CKRL is therefore designed to represent the important properties of rule 
conditions and conclusions. Our experience has shown us that, despite variations 
in syntax, there are a relatively small number of types of rule conditions and con- 
clusions; that is, there are a small number of different roles which conditions and 
conclusions can perform. Three basic classes of rule elements have been identi- 
fied, corresponding to the fundamental roles they play in rules. Figure 2 shows 
how these three classes are broken down into sub-classes. Tests can succeed or 
fail; e.g., retrievals from working memory, or comparisons such as ?Temp < 90 
where ?Temp is a variable name. Assignments assign a value to a variable, and 
always succeed. Expressions are rule elements that return a value, and again 
always succeed; e.g., arithmetical calculations or function calls. 



2.2 The Problem Graph 

The problem graph represents the KBS’s problem-solving for a particular refine- 
ment example. Figure 3 shows part of the problem graph generated by a faulty 
Mmu kb (the Mmu application is described in section 3). The graph consists 
of oval nodes representing facts, and rectangular nodes representing rule activa- 
tions. Nodes with a dotted outline represent knowledge that is currently not 
derivable but would help to correct the error. In Figure 3 the desired conclusion 
is (conclusion cea-failure-side-a), but the system is unable to reach any 
conclusion, though a number of intermediate results are derived. The dotted 
nodes show alternative ways in which the desired conclusion could be reached. 

The solid, or positive part of the problem graph, represents knowledge that 
was applied during problem solving for a particular example. It is constructed by 
translation from the execution trace. The dotted, or negative part of the problem 
graph, represents knowledge that was not applied during problem solving, but 
which could lead to the desired conclusion. 

The problem graph is used by the refinement routines to determine what 
changes to the rule base will cause it to generate the desired conclusion (s). 
There are two possible primitive types of refinement: logical refinements, and 
conflict resolution refinements. These can be combined to form more complex 
refinements. Logical refinements either enable a desired conclusion, as in figure 3, 
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Correct conclusion, 
which faulty KB fails 
to generate. 



(conclusion cea-failure-side-a) 




\fthis rule can be made to fire, 
it will contribute to producing 
the correct conclusion 



Fig. 3. A Sample Problem Graph 



or prevent an undesired conclusion. To enable a conclusion, the KrustTooI ena- 
bles any one rule which matches that conclusion. To enable a rule, for each failed 
antecedent the KrustTooI either weakens that antecedent so that it is satisfied 
for the refinement case, or else applies the algorithm recursively, enabling a rule 
whose conclusion satisfies the failed antecedent. Conflict resolution refinements 
change rule priority, when for example, a rule we wish to fire is activated but 
then de-activated before firing [3]. 

3 Evaluation Using Two Applications 

KRUSTWorks has been applied to various artificial and real-world KBSs. It has 
recently been evaluated on two industrial KBSs: Amfesys and Mmu. Here for 
reasons of space we concentrate on the results from Amfesys, and refer briefly 
to the results from Mmu. The Amfesys system was used by the European 
Space Agency in the control of the Automatic Mirror Furnace payload of the 
EURECA mission. Amfesys is written using Intellicorp’s PowerModel (for- 
merly Kappa). Much of the system is written in a version of C, but the fault- 
diagnosis module is written as 67 rules in the Pro-Talk scripting language. It is 
to these rules that KRUSTWorks was applied. The Mmu system performs auto- 
matic fault diagnosis, isolation and recovery procedures for the NASA’s Manned 
Maneuvering Unit. It is written entirely in Clips, and consists of 104 rules. 

For the purposes of our evaluation, we assumed that our copies of Amfesys 
and Mmu were correct. For each application, we constructed a sample problem 
set, then used the original KBS as an oracle to generate solutions for these 
problems. We next created a number of corrupted KBs, and for each KB, per- 
formed cross-validation experiments to determine how successful KRUSTWorks 
is at fixing the faults. 
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3.1 Construction of Sample Problems and Corrupted KBSs 

Applying KRUSTWorks to Amfesys required some modification to the interface 
between the diagnostic rules and the rest of Amfesys. The rules determine 
the state of the satellite model by accessing object slot values, and by calling 
functions defined elsewhere in the Amfesys system. We ran the entire system 
for a period of time, during which it executed the diagnostic rules in a series of 
different situations, corresponding to our training examples. We determined the 
values read by the rules for each example, and then modified the rule interface 
so that it could be “initialised” to any particular example, after which it would 
pass the values associated with that example to the diagnostic rules. Applying 
KRUSTWorks to Mmu was more straightforward, since Mmu is a stand-alone 
rule-set. 

For each application, five faulty KBs were generated, each constructed by 
making a single change to the original rule base. These were primitive changes 
such as: added condition, modified threshold value, modified right-hand side 
in an equality test, modified Clips field constraint, and modified condition in 
a nested disjunctive structure. For each KB, changes were selected that were 
applicable to that KB. Further faulty KBs were then generated by combining 
the single faults into all possible groups of two and three faults. Finally, a KB 
containing all five faults was constructed. For each application, the faults were 
numbered 1 through 5, and the corrupted KBs were assigned names indicating 
the faults they contain; e.g. Amfesys123 contains faults 1, 2 and 3. 

3.2 Refinement Experiments 

For each corrupted KB, an n-fold cross-validation was performed. The example 
set for the application was randomly divided into 5 equal subsets, which were 
then repeatedly partitioned into training and testing sets in the ratio 3:2, giving 
10 experiments. For each experiment, a KrustTooI was applied iteratively to 
the training examples as shown in figure 1. Both the initial corrupt KB and the 
final refined KB were then evaluated on the testing examples. Table 1 shows 
the results for the two most corrupted KBs: Mmu12345 and Amfesys12345, 
each with 5 faults. These figures show that a KrustTooI was able to make 
considerable improvements to the most corrupt KBs, but could not always reduce 
the error-rate to zero; and for this particular pair of KBs, the results for Mmu are 
better than for Amfesys. The reasons for the non-zero error rates are explained 
in the next section. 

3.3 Amfesys Results 

The Amfesys KrustTooI was almost always able to fix the faults when pre- 
sented singly, provided that the training examples offered fault evidence. There 
were three situations in which the tool did not produce the desired improvement 
in error-rate. First, when none of the examples in the training set exhibited the 
fault. Second, when none of the examples in the testing set exhibited the fault. 
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Table 1. Error rates before and after refinement 



Error Rates 

Mmu12345 Amfesys12345 



Run 


Initial KBS 


Final KBS 


Initial KBS 


Final KBS 


1 


0.0625 


0.0 


0.7647 


0.1176 


2 


0.125 


0.0 


0.8235 


0.0588 


3 


0.125 


0.0 


0.9375 


0.0 


4 


0.1562 


0.0312 


0.6471 


0.0588 


5 


0.1562 


0.0312 


0.75 


0.0 


6 


0.2187 


0.0312 


0.75 


0.0625 


7 


0.0937 


0.0 


0.7647 


0.0588 


8 


0.0937 


0.0 


0.875 


0.125 


9 


0.1562 


0.0 


0.9375 


0.25 


10 


0.1875 


0.0312 


0.6875 


0.0 



so that a fix did not improve the test set’s error rate. Third, when an incorrect 
fix was randomly selected because it performed as well as the correct fix. 




Corrupt KB 



Fig. 4. Improved error rates for Amfesys KBs 



Fault 2 (incorrect threshold value) illustrates the first situation. None of 
the examples exhibited this fault, so the tool could never fix it. Faults 4 and 
5 illustrate the third situation. For both faults, the tool occasionally selected 
sub-optimal refinements, so that the error rate improved, but not to 0. Figure 4 
summarises the results. The bars for each KB represent the number of runs in 
which the accuracy on the testing set was, respectively, unchanged, improved 
but not to perfect accuracy, and improved to perfect accuracy. For the multiple- 
fault KBs, the error rate for the final refined KB was always reduced from the 
initial corrupt KB. The graph shows that the incorrect refinement selection for 
faults 4 and 5 already noted was slightly exacerbated by the presence of other 
faults, so that, for example, the tool performed slightly worse on Amfesys14 
than on Amfesys4. However, KBs containing combinations of faults 1, 2, and 3 
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only were always refined to perfect accuracy. For Mmu, as with Amfesys, the 
KrustTooI was able to fix the faults when presented singly, provided that the 
training examples gave evidence of the fault. 



3.4 Lessons from the Evaluation 

Our experience with Amfesys showed that it is possible to refine a KB even 
when it is included as part of a larger system which is not rule-based; the use of 
a KB in this way is common in industrial expert systems. 

Secondly, situations arose when a faulty refined KB disrupted the experi- 
ments. For example, some refined Mmu KBs ran forever. An ideal solution would 
have limited the resources allowed when executing a refined KB. In practice, we 
imposed an extra constraint on the KrustTooI so that it would not genera- 
lise either of the rules which caused this problem when refined. Other refine- 
ments caused runtime errors, as illustrated by the following pair of conditions: 
?DiagH != unknown; ?Delta = ABS(?DiagH-?ModelH) ; 

If a refinement removes the first condition, a runtime error will occur if the rule is 
executed with ?DiagH bound to unknown. We therefore modified the KrustTooI- 
KBS interface to kill a crashed KBS process and restart it, rejecting the refined 
KB that caused the error. Thus we can either make KrustTooIs employ complex 
reasoning to determine in advance whether a KB will generate a run-time error, 
or else implement a KrustTooI-KBS interface which recovers from such errors. 
Because of the difficulty of correctly implementing the predictive approach for 
all KBS shells, we opt for error-recovery. 



4 Related Work 

Clips-R [4] uses a wider definition of KBS behaviour than other systems, inclu- 
ding content of working memory when execution halts, and the order in which 
actions are performed which display or request information. Clips-R constructs 
an explicit representation of the KBS’s reasoning in a trie structure, which groups 
together those rule traces which share an initial sequence of rule firings. 

Both Etzioni [5] and Smith & Peot [6] create structures similar to our negative 
problem graph, but in the domain of planning. These structures are built like 
ours by backward chaining from the final goal, and are used to improve the 
subsequent performance of the planners. Etzioni uses the problem space graph 
to guide operator use. Smith & Peot’s operator graph warns which operator 
conditions have the potential to lead to recursion. 

Fensel et al. [7] take a more general approach than the authors so far men- 
tioned, building ontologies for both tasks and problem-solving methods (PSMs). 
These ontologies state the abilities of each PSM, and the requirements of each 
task, thus allowing an adapter to select a method appropriate for a given task. 
This approach allows PSMs to be written in a task-independent way, and so 
to be applied to a range of tasks. KRUSTWorks’ refinement operators therefore 
correspond to the PSMs, and the knowledge hierarchy forms a PSM ontology. 
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5 Conclusions 

Most refinement tools apply to a single KBS environment. We have presen- 
ted an alternative approach which uses generic representations for the rules, 
and for the reasoning process of a KBS. This has enabled us to build a set of 
KBS-independent tools, applicable to a variety of KBS environments. In this pa- 
per, we have described an evaluation of these tools as applied to two industrial 
applications written in the PowerModel and Clips shells. Our experiments 
have shown that the generic KRUSTWorks approach to refinement is feasible. 
The KRUSTWorks core refinement techniques and toolkit of operators were ap- 
plicable to two different industrial applications written in two different shells. 
Secondly, the tools were generally able to identify and fix artificial corruptions in 
both shells. When the tools were unable to fix faults, the major cause was a lack 
of fault evidence in the available examples. Our experiences also confirmed that 
a generic refinement tool should be designed to recover after run-time errors in 
faulty refined KBS, rather than trying to predict them in advance. 
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Abstract. An electronic business model is an important baseline for the deve- 
lopment of e-commerce system applications. Essentially, it provides the design 
rationale for e-commerce systems from the business point of view. However, how 
an e-business model must be defined and specified is a largely open issue. Business 
decision makers tend to use the notion in a highly informal way, and usually there 
is a big gap between the business view and that of IT developers. Nevertheless, we 
show that conceptual modelling techniques from IT provide very useful tools for 
precisely pinning down what e-business models actually are, as well as for their 
structured specification. We therefore present a (lightweight) ontology of what 
should be in an e-business model. The key idea we propose and develop is that an 
e-business model ontology centers around the core concept of value, and expresses 
how value is created, interpreted and exchanged within a multi-party stakeholder 
network. Our e-business model ontology is part of a wider methodology for e- 
business modelling, called — value, that is currently under development. It is 
based on a variety of industrial applications we are involved in, and it is illustrated 
by discussing a free Internet access service as an example. 



1 Introduction 

The design of an electronic commerce application is in our view not primarily an IT- 
oriented activity. Rather, it consists of very different types of design problems [10]. 
The most important of these is the design of the e-business model which highlights the 
way of doing business. A business model should do so in a very precise way, because 
stakeholders such as chief executive officers, marketers, and business developers should 
agree on it, and because it is a crucial bottomline part of the requirements for an electronic 
commerce system. For example, how do we develop the IT infrastructure and application 
system for a free Internet service? This cannot be really done without knowing what the 
underlying business model for the service is in the first place. 

Therefore, we propose an ontology [3,6] to define from a generic point of view 
what should be in an e-business model. The key idea we propose and develop in this 
paper is that an e-business model ontology centers around the core concept of value. 
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and expresses how value is created, interpreted and exchanged within a multi-party 
stakeholder network of (extended) enterprises and customers. It is exactly this notion 
of value which is currently lacking in information modelling and analysis approaches, 
including various business-oriented ontologies that have been developed recently. 

The present work is part of a broader methodology for e-business development, 
called -value, we are currently developing [10]. It reflects and structures the strategic 
business decisions that need to be made at the executive level on the e-business model 
and on business-IT alignment, before one can proceed to the technical design of an 
electronic commerce system. In Sec. 2, we discuss the need for an e-business model 
ontology. Sec. 3 describes our e-business model ontology, and we illustrate it by a case 
study. In Sec. 4 we discuss related work, and we briefly summarize the practical use of 
the ontology in consultancy and application projects. 

2 The Need for a Business Model Ontology 

Normally, the design of an electronic commerce system starts with the development 
of a business model. In most cases, such a business model is written down in natural 
language, perhaps with some informal sketches. The concepts and their interpretations 
used to describe a business model vary across different stakeholders, and this leads to 
important obstacles to achieve business-IT alignment in e-commerce applications. Given 
the enabling role of IT in electronic commerce, this alignment problem is no longer just 
an engineering issue: it has a strategic significance. 

During the design of a business model, an ontology is therefore useful to prescribe 
which concepts and relations have to be present in a business model. An ontology should 
provide a reusable conceptualisation, in this case of the concept of e-business model, 
on which people can agree. By specializing and instantiating concepts and relations of 
the ontology for a particular case, the ontology can also be used to describe a particular 
business model in a precise and structured way. In the present context, we are mainly 
interested in ways to enhance communication between various stakeholders, that is, in 
shared meaning rather than automated reasoning. Thus, our current goal is to construct 
a so-called ‘lightweight’ ontology [16]. 

Furthermore, a business model ontology shows designers what kind of decisions 
should be taken during business model development. If stakeholders agree on a particular 
business model, a number of business decisions have been taken, so that the model 
serves as a precise set of business requirements for the electronic commerce information 
system. These requirements are useful for software architects who design the electronic 
commerce system from a technical point of view. 

An ontology for e-business models must be capable of representing a range of busin- 
ess issues. These issues center, and this is our key proposal, around the generic concept 
of value, and how to create and exchange it in a network setting. Value is a central notion 
emerging from the scientific economic and business literature on e-business. Our prac- 
tical experience in application projects also shows it to be a natural and useful concept 
for executives to focus on. 

Informally, a business model highlights a network of actors and how they create or 
consume objects of value. These actors can be private persons, companies or enterprise 
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alliances. Furthermore, a business model represents the services offered by and requested 
from actors. It should be capable to represent if an actor is willing to exchange an object 
of value (e.g., the right to listen to a music track) for another object of value (e.g., 
money). Also, a business model illustrates which actors can have economic transactions 
with other actors. A transaction is possible if actors offer each other objects of value 
in which both have a mutual interest. Finally, actors must perform activities to create 
value; for other actors or even for themselves. The assignment of activities to actors is an 
important element in e-business models for decision makers. The above business model 
concepts, which are more formally expressed in our -value ontology, originate from 
scientific studies from a variety of (non-IT) disciplines, in particular marketing [17], 
axiology [13], business administration [18,19], and emerging e-commerce theory [4,15, 
2 1 ]. In the next section, we present a lightweight ontology that is capable of representing 
these business issues to various kinds of stakeholders. 



3 An Ontology for E-Commerce Business Models 

The e^-value ontology contains concepts, relations, and constraints, to describe actors, 
alliances between them, the exchange of objects of value, the value-adding activities, 
and the value interfaces between them. We identify three different views for describing 
business models for specific business cases. The global actor view shows which parties 
are involved in a business model and which objects of value they exchange. Its main 
purpose is to explain the overall business model to a wide range of stakeholders. The 
detailed actor view takes a further look at the decomposition aspects. It shows, for 
actors identified in the global actor view, alliances between parties, for instance virtual 
enterprises [5]. Finally, the value activity view shows the assignment of value-adding 
activities to actors. The ontology is illustrated by a small case study about a free Internet 
access service. In The Netherlands, a number of parties are offering such a service. 
Suppose one is asked to develop the business model of such a service (in actual fact, 
our example is taken from a real-life case). We show that our ontology can be used to 
answer such a ’fuzzy’ question. 



Global actor view. Figure 1 shows the global actor view of a business model for the 
free Internet access service. Its main purpose is to illustrate the overall business model 
to all stakeholders. The global actor view shows actors involved, such as surfer and free 
Internet provider, and the exchange of value objects between them. A value exchange has 
a direction, visualized by an arrow, indicating the direction the value object ‘flows’. In this 
case, the surfer pays the free Internet provider. Value exchange links start and end at value 
ports. These ports are not visualized explicitly at this global level; they are the points 
connecting the value exchange with actors. Ports are grouped into a value interface, 
modelling the service an actor offers to its environment (also not drawn explicitly at this 
level). We note that this concept of ports and interfaces actually stems from ontologies 
relating to systems theory [3]. Some value exchanges relate to each other, for instance 
payment and Internet access. This is called an offering. In an offering both exchanges 
need to occur: there is no Internet access possible without payment and vice versa. Note 
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that, apparently, the free Internet access service is actually not for free at all: a surfer has 
to pay for the telephone connection. 




Fig. 1. Business model for the free Inter- 
net case: the global actor view. 




Fig. 2. Core concepts in the -value on- 
tology of e-business models (global actor 
view). 



The business model in Figure 1 is a specialization and instantiation of concepts and 
relations in the e^-value ontology (Figure 2). They are discussed in more depth in this 
section, and so are the specialization and instantiation of concepts and relations in the 
ontology for the free Internet access business case. The explanation of our ontology 
is structured by presenting a description for each concept, properties of the concept, 
relations with other concepts, constraints, and the visualization in a business model such 
as depicted in Figure 1. Each concept and relation is illustrated by a practical example. 

Actor. An actor is perceived by its environment as an independent economic (and often 
also legal) entity. Enterprises, strategic business units, and customers are examples of 
actors. 

Properties. An actor may have a name, e.g. a company name. 

Example. We identify three specializations of the actor concept: (1) the surfer actor, 
(2) the free Internet provider actor, and (3) the peering provider actor (Figure 3). The 
surfer actor uses the free Internet provider to surf the Internet. The free Internet provider 
uses peering providers to deliver traffic at the Internet host the surfer selected. Peering is 
necessary for an interconnected network of Internet hosts. Instances of surfer (si, s2,.., 
sn) , one instance of free Internet provider (fl) and a number of instances of peering 
provider (pi, p2,.., pn) are represented in Figure I. Note that worldwide, a number of 
free Internet providers exist, but here we are only interested in one. 

Value Object. Actors exchange value objects. A value object is a service or product 
which is of value for the actors. Actors may value an object differently and subjectively, 
according to their own valuation preferences [13]. 

Properties. A value object has one or more valuation properties. A valuation property 
has a name and a unit which indicates the measuring scale in which the valuation is 
expressed. In general, the quantification of value has to be done by means of a multi- 
dimensional utility function [2,9]. 
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Fig. 3. Specialization of the actor con- 
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Fig. 4. Specialization of the value object 
concept. 



Example. Internet access is a specialization of value object and represents the service 
offered by the free Internet provider to surfers. Internet access is valued in terms of 
connection time which is expressed in seconds and the Committed Information Rate 
{CIR), measured in bits per second. Other value objects are money and Internet peer 
connectivity (Figure 4). 

Value Port. An actor uses a value port to provide or request value objects to or from its 
environment. Thus, a value port is used to interconnect actors so that they are able to 
exchange value objects. The concept of port is important, because it enables to abstract 
away from the internal business processes, and to focus only on how external actors 
and other components of the e-business model can be ‘plugged in’. This is the value 
analogue of the separate external interfaces familiar from technical systems theory [3]. 
Take, for example, a bipolar in+out value multi-port, which is the most characteristic 
combination occurring in e-business models: an e-service port out and a money port 
in, or the other way around. Such a bipolar value port combination can be very well 
compared to an electrical wall outlet. As an external user, you don’t want to be involved 
in what happens behind the wall outlet as long as it gives the right quality of service. 
The same approach holds for how external parties in an e-business model view the value 
ports of a service-offering actor: the ports only define how the external connections to 
other actors should be made. 

Relations. Value ports offer or request value objects. A value object can be requested 
or offered by multiple value ports. 

Example. Consider the Internet access port, as a specialization of the value port 
concept. The offer or request relation is specialised into a relation between the Internet 
access value port and the Internet access value object (Figure 5). The business model 
(Figure 1) shows two instances of the Internet access port. The surfer has an in-port and 
the free Internet provider has an out-port. 

Value Interface. Actors have one or more value interfaces. A value interface groups 
individual value ports. (One can see this as a direct analogon to how a wall outlet is an 
assembly of plug-in ports in a technical system). It shows the value objects an actor is 
willing to exchange in return for other value objects via its ports. 

Properties. A value interface has a valuation function. It expresses, given valuation 
properties of objects of all in-ports, the required valuation properties of objects on all 
out-ports, and vice versa. In other words, a valuation function shows if an actor is 
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willing to exchange value objects in return for other value objects. The valuation of 
objects depends on a specific actor evaluating the valuation function [13]. The valuation 
function has a direction argument. If the direction is in, the valuation function returns 
the required valuation properties of the value objects on all in-ports. If the direction is 
out, the opposite happens. 

Relations. A value interface is assigned to one actor and has zero or multiple in 
value ports and has zero or multiple out value ports. A value interface has at least one 
value port. Multiple value interfaces can be assigned to an actor and a port belongs to 
exactly one value interface. If an actor has multiple value interfaces, s/he is offering 
different services to the environment. 

Constraints. The exchange of value objects is atomic at the level of the value in- 
terface. Either all exchanges occur as specified in the value interface or none at all. For 
instance, a surfer cannot obtain Internet access without paying. The value interface says 
nothing about the time ordering of objects to be exchanged on its ports. It simply states 
which value objects are available, in return for some other value objects. 

Example. The surfer has a specialized value interface called S-Internet-access which 
consists of a payment out-port and an Internet access in-port. It is important to recognize 
that the Internet access service is not free at all. The surfer has to pay for its telephone 
connection. The free Internet provider has a similar interface, with opposite port direc- 
tions (Figure 6). Note that cardinality constraints for the has-out and has-in elations are 
specified more strictly for the specialization. For example, an S-Internet-access value 
interface consists of exactly one payment port and exactly one Internet-access port. 

Value Exchange. A value exchange represents the trade of a value object between value 
ports. There are different kinds of value exchanges. First, seen from a port of an actor, 
value exchanges may occur to other ports of, possibly different, actors (Figure 7(a)). 
For instance, the port of actor A offering music can do so to ports of different actors 
B and C. This models the situation that multiple actors buy a track of music. Second, 
it is possible that a number (> 2 ports) are involved in one particular value exchange. 
The following two situations may then occur. Figure 7(b) represents a split of the value 
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object, in this case, an amount of money. Actor A pays an amount of money to actor 
B and C in one value exchange. The situation in Figure 7(c) models duplication of a 
value object. Duplication of a value object is only possible if the marginal costs to create 
a replica are zero. This may be the case for value objects such as music, video and 
information. Actor B and C both receive a duplicate of a music track of actor A in one 
value exchange. 




(a) value exchanges between (b) value object (c) value object duplicates 
different ports splits 



Fig. 7. Different types of value exchanges. 



Relations. The value ports involved in a value exchange are represented by the 
between relation. At least two value ports participate in a value exchange. A value port 
can be in multiple value exchanges. 

Constraints. A value exchange occurs between ports of opposite directions. A value 
object flows from an out-port into an in-port. Therefore, at least one in-port and one 
out-port should be present in a value exchange. Value ports can be seen as the end-points 
or terminals of a value exchange. 

Example. An Internet access exchange is a specialization of a value exchange. In 
an Internet access value exchange, exactly two value ports participate (Figure 8). Value 
exchanges occur between surfers and the free Internet provider. 




spccialisatbn 



Legend: 

Offering 



Fig. 9. Ports in an actor’s interface 

Fig. 8. Specialization of the value connected to ports of two other actors, 
exchange concept and relation. 



Value Offering. A value offering is an assembly of value exchanges. In an offering, value 
exchanges between multiple actors (> 2) can participate. 

Relation. A value offering contains a number of value exchanges. A value exchange 
participates in exactly one value offering. 
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Example. A free Internet access offering contains exactly one Internet-access 
exchange and one payment exchange (Figurre 1 0). The two value exchanges between the 
free Internet provider fl and the surfer si clearly are an offering (Figure 1). The same 
holds for the value exchanges between the free Internet provider fl and the peering 
provider pi. 




Fig. 10. Specialization of the value offering concept and relation. 



Market segment. In the marketing literature [17], a market segment is defined as a 
concept that breaks a market (consisting of actors) into segments that share common 
properties. Accordingly, our concept market segment shows a set of actors that share 
a similar valuation function. Consequently, because valuation functions are bound to 
value interfaces, actors in a segment all have at least one similar value interface. Value 
exchanges and value offerings drawn to a segment are a shorthand notation for value 
exchanges and offerings between all actors of the segment, and other actors. Figure 1 1(a) 
shows an actor exchanging values with three other actors. Figure 1 1(b) shows the same 
but now with the three actors having a similar valuation function. 

Properties. A market segment has a count, which indicates the number of actors in 
the segment. The count can be a number, unbounded, or unknown. 

Relations. Value interfaces of actors are part of zero or more market segments. A 
market segment contains one or more value interfaces. 

Constraints. Value interfaces of actors in a market segment should all have a similar 
valuation function (shown as a ‘stack’ of actors). Note that actors in a segment may also 
have in-similar value interfaces. 

Example. It is reasonable to expect that, with respect to the valuation function, a 
number of different surfers exist. Some surfers are willing to pay quite some money for 
high quality Internet access (heavy surfers) while others are only interested in sending 
low-bandwidth email and want to pay a small amount of money (light surfers). These 
can be grouped in a heavy surfer segment and a light segment (Figure 12). 

Discussion. The global actor view shows the most important actors in a business model. 
Furthermore, it shows the objects of value exchanged between these actors, as well as 
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(a) business model without (b) business model 
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Fig. 11. A business model without and with mar- Fig. 12. Specialization of the market 
ket segment. segment concept and relation. 



offerings. The market segment notion is useful if offerings are of interest to a number 
of actors who share the same valuation function. The global actor view can easily be 
constructed in brainstorm sessions and workshops with all key actors. Also, this view 
can be used to present and explain the overall business model to stakeholders. For the 
free Internet access service, the global actor view illustrates that the free Internet access 
service is offered to surfers. However, the service is not for free at all, since the surfer has 
to transfer money for Internet access. This is due to costs for the telephone connection (a 
B2B e-business approach known as revenue sharing). Also, this view shows that, to offer 
an Internet access service, peering services have to be contracted with peering providers. 



The detailed actor view: decomposition aspects. The purpose of the detailed actor 
view (Figure 13) is to show alliances between actors. For reasons of space we only show 
and discuss the detailed actor view for the free Internet provider. A detailed actor view 
can be developed for the peering provider as well. 

Composite actor and elementary actor. An actor is perceived by its environment as an 
independent economic (and often also legal) entity. However, for providing a particular 
service, a number of actors may decide to present themselves, as a single (virtual ent- 
erprise) actor to their environment. Such actors decide on one or more common value 
interfaces to their environment. We call such a group of actors a composite actor. Actors 
can be composed of other composite actors and/or elementary actors. In the global ac- 
tor view we do not state explicitly whether an actor is elementary or composite. In the 
detailed actor view, we refine actors of the global view into their constituents. 

Relations. A composite actor is an actor. An elementary actor is an actor. A composite 
actor decomposes into other actors. Actors may be part of zero or more composite actors. 

Example. Telecommunication company and free Internet access provider are specia- 
lizations of the elementary actor concept. A telecommunication actor offers physical 
connectivity for data transport. A free Internet access provider offers Internet access. 
These actors jointly offer a free Internet service, resulting in a composite actor cal- 
led free Internet provider (Figure 14). TelCo and FastNet (Figure 13) are instances of 
Telecommunication company and free Internet access provider, respectively. 
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Legend: 
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Fig. 13. Business model for the free Internet case: the detailed actor view. 
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Fig. 14. Specialization and decomposi- 
tion of the actor concept. 



Fig. 15. Specialization and decomposi- 
tion of the value object concept. 



Composite value object and elementary value object. Composite value objects can be 
decomposed into other value objects. A composite value object can be built from other 
value obj ects which may be provided by different actors. Elementary value obj ects cannot 
be decomposed any further. A value object can be in only one composite value object. 

Relations. An elementary value object and a composite value object is a value object. 
A composite value object decomposes into other value objects. 














What’s in an Electronic Business Model? 



267 



Example. Physical connection and Internet connection are specializations of the 
elementary value object. These value objects can be composed to form Internet Access 
(Figure 15). 

The exchange of value. A composite actor has a value interface to its environment. 
Flowever, a value interface of a composite actor must be mapped onto one or more value 
interfaces of actors which are part of the composite. This mapping is represented by 
value exchanges and value offerings. To be able to present these mappings accurately, 
we use a rounded box to visualize a value interface of an actor and an arrow to presents 
a value port of the value interface. The direction of the arrow indicates whether a value 
object flows in or out the actor. In Figure 16, a composite actor al is shown, consisting 
of actors bl and b2. The ports in the value interface of al are connected using value 
exchanges with value ports of bl and b2. On port pi, a value object is offered to the 
environment of actor al. This object is offered by port p3 or by port p5. Another object 
of value is requested in return on port p2. Internally this object is split in two objects, to 
port p4, and port p6. 

Relations. The value ports involved in a value exchange are represented in the 
between relation. 

Constraints. All connected ports in value exchange should have direction in or out. 

Example. The free Internet provider consists of two actors: Telecommunication com- 
pany TelCo and free Internet access provider FastNet. These companies are jointly of- 
fering an Internet access service. The externally visible value port Internet access of 
the free Internet provider is mapped onto the physical connection port of TelCo and the 
Internet connection port of FastNet. The other externally visible port of the free Internet 
provider is the payment. This port is mapped onto the payment port of TelCo because 
TelCo receives payment of the surfer. 



pi p2 




Fig. 16. Value exchanges between a composite actor and its composites. 



Discussion. The detailed actor view intends to represent actors jointly offering or re- 
questing a product or service. For each actor in the global actor view, detailed actor 
views may be considered. Such a detailed view consists of actors sharing a particular 
value interface to their environment. Furthermore, the detailed actor view shows how 
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the shared value interface is mapped onto value interfaces of the actors themselves. The- 
refore, in the detailed actor view we make the value interfaces and value ports explicit. 
Note ihatFastNet and 7e/co jointly only offer the Internet Access service. FastNet itself 
has a value interface for Internet peering; TelCo has nothing to do with this. 



The value activity view. We now discuss the value activity view. Its main purpose is to 
illustrate the assignment of value-adding activities to actors. Figure 17 shows this view 
for TelCo and FastNet. How value-adding activities are assigned to the various possible 
actors is a free variable that, as a result of the extended enterprise network setting, leads 
to many design options and choices in e-business models. Hence, this assignment is a 
key consideration in strategic e-business decision making. 




Legend: 




Fig. 17. Business model for the free Internet case: the value activity view. 



Value Activity. A value activity is performed by an actor and produces obj ects of value for 
an actor. Both these actors can be different entities but they may also coincide. Consider 
an actor listening to music s/he bought in order to have a nice experience. In such a 
case, the actor performs a value activity (listening) and produces an object of value for 
him/herself (namely, a nice experience: note that what constitutes value may be rather 
abstract and interpretive). An important issue in e-commerce business model design is 
the assignment of value activities to actors. Therefore, we are interested in the collection 
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of activities which can be assigned as a whole to actors. Such a collection we call a value 
activity. Therefore, the granularity of value activities should be such that they can be 
performed economically independent from other value activities [19], and they cannot 
be further decomposed into smaller economic activities that can be assigned to different 
actors (this gives a decomposition stop rule, which is by the way clearly different from 
business process or workflow decomposition). Value activities can be assigned to an 
elementary actor but also to a composite actor. In the latter case, the composite actor is 
not composed of other actors only (such as a virtual enterprise), but it can perform value 
activities by itself. 

Relations. A value activity has one or more value interfaces. A value interface 
belongs to exactly one value activity. A value activity is assigned-to precisely one actor. 
Multiple value activities can be assigned to an actor. 

Example. The value activity concept is specialized into the call-delivering and Inter- 
net access value activity. A call-delivering value activity has two value interfaces: (1) 
the connection interface, modelling a physical connection service which has to be paid 
for, and (2) an acceptance interface which models that a connection should be accepted 
by someone else, before one can speak of a connection (Figure 18). FastNet, which has 
been assigned the Internet access value activity, accepts physical connections for TelCo. 



Ontology 




assigned-to 



free Intcmd: 
business 
model 




specialisation 



assigned-to 



has 



Fig. 18. Specialization of the value activity concept and relations. 



Discussion. The value activity view shows which value activities are assigned to spe- 
ciflc actors, and how value interfaces of these activities map onto value interfaces of 
actors. For the free Internet access service, the assignment of value activities is rather 
arbitrary. However, alternatives, not considered in this paper, are to assign the value 
activity Internet access to TelCo also, or to assign the value activities Internet access 
and call delivering to a telecommunication company only. Such alternative assignments 
would also lead to changes in the detailed actor view: they constitute different business 
models. 
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4 Discussion and Conclusion 

Related work. There are some related business-oriented ontologies, in particular the 
AIAI enterprise ontology [22] and the TOronto Virtual Enterprise Ontology (TOVE) [7] . 
The most important difference with our -value ontology is that we focus on the notion of 
value and the way objects of value are created, exchanged and consumed in a stakeholder 
network, while the enterprise ontology and TOVE concentrate on the enterprise itself, 
the latter resulting in a business process rather than external value perspective. 

AIAI enterprise ontology. The enterprise ontology defines a collection of terms and de- 
finitions relevant to business enterprises. Two enterprise ontology concepts relate to our 
ontology but have a different interpretation: (1) activity and (2) potential sale. In the ent- 
erprise ontology, activity is the notion of actually doing something, the how. Our related 
definition, value activity, abstracts from the internal process and in contrast stresses the 
externally visible outcome in terms of created value, independent from the nature of the 
operational process. Thus, the defining boundary of what an activity is differs: in the 
e^ -value ontology the decomposition stop rule is to look at economically independent 
activities; business process or workflow activities have different decomposition rules, 
as such activities need not be economically independent. The enterprise ontology fur- 
ther defines a potential sale as a possible future agreement between two legal entities 
to exchange one good for another good. In our ontology, the concept of potential sale 
roughly corresponds to the concept of offering. An offering contains value exchanges. 
In the enterprise ontology, only two goods are exchanged in a potential sale. In contrast, 
in our ontology an offering contains an arbitrary number of value exchanges. This is 
needed to model a bundle of goods that is offered or requested as a whole. Furthermore, 
our ontology is capable of multi-party offerings. The case study in this paper illustrates 
the need for such a concept. 

Toronto Virtual Enterprise Ontology. The TOVE ontology identifies concepts for the 
design of an agile enterprise. An agile company integrates its structure, behaviour and 
information. The TOVE ontology currently spans knowledge of activity, time and cau- 
sality, resources, cost, quality, organization structure, product and agility. However, the 
interfaces an enterprise has to its environment are lacking in TOVE. Generally, the no- 
tion of the creation, distribution, and consumption of value in a stakeholder network is 
not present in the TOVE ontology. Hence, the TOVE ontology concentrates on the inter- 
nal workflow of a company, whereas our ontology captures the outside value exchange 
network. 

System-theoretic ontology. As pointed out earlier in this paper, the e-business ontology 
reuses several concepts from general and technical systems theory and associated on- 
tologies [3]. In particular, the introduction of the concepts of ports and interfaces of a 
(network) system help to abstract away from the internal workings of an activity (or 
subsystem), and to independently specify the connection to the environment (external 
suubsystems). This is an important advance over what is typically done in business 
process and workflow modelling [8]. 
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Use of the ontology in e-business development. In summary, this paper is premised 
on the observation that for the development of electronic commerce systems, e-business 
models must be specified precisely. Such a clear-cut specification is important for two 
reasons: (1) to reach agreement between stakeholders involved, and (2) to be able to 
serve as a specification for designers of the commerce system. The -value ontology 
discussed in this paper specifies which generic concepts have to be present in an e- 
business model. These concepts are based on the generic and reusable notion of value, 
and are capable of representing creation, exchange, valuation, and consumption of value 
objects in a network of actors. 

Of course, for e-business development an ontology is only one of the necessary 
tools. It must be embedded in a wider process of e-business modelling and application 
development. The present paper is rather descriptive in nature, but the ontology has 
several more dynamic and practical uses in e-business development that are beyond the 
scope of this paper. In brief 

1 . The e^ -value ontology gives a baseline of shared concepts with which it is possible 
to construct e-business models. This baseline is much more rigorous, and therefore 
more amenable to IT systems follow-up, than value-oriented business approaches 
such as [18,19]. It is also richer as it handles external value networks and not just 
value chains — an extension we believe to be essential for e-commerce. 

2. It is our practical experience in industry projects that e-business models (on the 
basis of this ontology, especially the global actor view) can be constructed during 
workshops or brainstorm sessions with stakeholders such as executive management, 
and that this type of value analysis is felt as helpful and illuminating. This is similar 
to experiences with management workshops in knowledge management, see e.g. [1, 
20 ]. 

3. We have developed a set of steps, business rules and guidelines, and scenario tech- 
niques for practitioners (rooted in the ontology concepts) that structure, steer and 
simplify the process of designing and evaluating e-business models. More on this 
process is found in [10,11]. 

4. Our ontology has been described in this paper in a graphical and semi-formal way. 
This is in line with its use as a lightweight ontology to enhance communication 
between different stakeholders [16]. However, tool development is ongoing, and a 
working Prolog implementation of the ontology has been constructed. There are thus 
no significant obstacles to formalize e^ -value in terms of one of the formal language 
approaches to ontology [6,14]. Furthermore, it is not difficult to define our graphical 
notation in terms of UML, using its standard extensions such as stereotyped classes 
and especially packages with associated icons. As this is straightforward technical 
labour not adding anything to the semantics, we have not discussed it in this paper. 

5. An important further step is to extend the work to a quantitative formulation of 
the concept of value. This would enable to analyze business scenarios and make 
choices between business models on quantitative grounds, by linking value analysis 
to methods and results from utility theory, decision theory and optimization. We are 
currently researching how to make the transition from qualitative and interpretive 
customer value notions [13] to quantitative utility analysis. For some application 
areas we have shown that this indeed can be done, see [9,2] for applications to web 
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selling of digital music content and to automatic cost-efficient building comfort 
management, respectively. 

6. At the IT level, this provides the basis for agent-based e-business system solutions. 
Corresponding, extensive and real-life applications where economic agents make 
local decisions based on utility considerations, are described in some of our other 
work [23,12,24,2]. 

Thus, an important virtue of the ontology approach is that it provides a foundation 
to express and discuss e-business models for specific business cases in a rigorous and 
structured fashion. This enhances business-IT alignment and smoothens the transition 
to e-commerce systems engineering. 
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Abstract. Two of the main issues that have permeated management thought in 
the 1990s are Business Process Re-engineering and Knowledge Management. 
The former rapidly achieved dizzying heights in terms of citations, publications 
and sales, before equally rapidly falling into disrepute. The latter may be 
following the same course; and perhaps deservedly so. If this seems to be an 
injustice to knowledge management, then the precipitous fall of BPR is also 
undeserved. This paper seeks to stress the strengths and weaknesses of these 
two trends, offering ways in which they can and should influence our practices. 
Taking a slightly tangential perspective to each provides the basis for a 
corrective to any tendency to fall into the trap of a mechanistic or IT- 
determined orientation; a potential inherent in both. The use of two slightly off- 
beat examples helps to illustrate the strengths and weaknesses of both 
phenomena. 



1 Problems with BPR and Knowledge Management 

For perplexed readers I should start by pointing out that my title is taken from two 
sources; an essay by Jorge Luis Borges The Chinese Encyclopaedia of John Wilkins’ 
and an analysis of Balinese cockfights by the anthropologist Clifford Geertz. 1 must 
also stress that unfortunately I have never been to Bali or China; I know very little 
about cockfighting, other than what I have gleaned from Geertz’ writing; and to the 
best of my knowledge 1 have never even seen a Chinese encyclopaedia, let alone read 
any part of one. 

What these two sources offer, however, is the opportunity to consider two critical 
and influential sets of concepts - one already well on the way to near complete 
dismissal as a management ’fad’, the other perhaps just starting on the same path of 
meteoric rise and equally precipitous decline. In both cases some salvage work and 
reassessment is required. In the case of BPR it is imperative to move beyond the 
mechanistic and lax conceptualizations that are usually associated with the term. With 
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knowledge management, at a far earlier phase in its development, there is still a need 
for clarification of basic tenets, and potential applications. 

By the mid-1990s BPR was in sharp decline as practitioners and researchers 
detailed the severe shortcomings in the organizational and management thinking that 
surrounded the re-engineering fad. This was particularly warranted with respect to the 
tendency of BPR towards what might be termed macho-mechanism', best exemplified 
by some of the statements made by Mike Hammer such as those reported in an 
interview for The Chicago Tribune in 1994. Here Hammer likened BPR to ’a neutron 
bomb’. 

Tor Hammer, the message of BPR is that companies must organize work around process. 
That means radically "reinventing" companies, not simply "fixing" them. It means tearing down 
hundreds, even thousands, of "functional silos" corporations have built. The walls remain 
standing, says Hammer, but everything inside is nuked . . .'[1] 

The savage imagery is a trait that Hammer seemed to display with relish. As will 
be argued below, however, the mechanistic mode of explanation is not limited to 
BPR; nor is BPR indelibly tainted by such tendencies. Unfortunately the 
understandable distaste for this mechanistic fallacy contributed to an underestimation 
of any positive contribution of BPR: Particularly its stress on process, both as a 
concept in itself and as a counter to the overwhelming bias towards structure and 
function. Some recent work has sought to accentuate the non-mechanistic aspects that 
can be found at the centre of BPR, and develop this into a basis for integrated 
business process management. Combined with developments such as those around the 
concept of the learning organization, this provides a link to emerging ideas centred on 
knowledge management. 

The term knowledge management does not (yet) seem to suffer from the same 
negative connotations that beset BPR; but in many respects it is far more problematic. 
A cynic might view the emergence of knowledge management as a case of ’locking 
the stable door after horse has bolted’: The mass redundancies and down-sizing of the 
past decade - often done under the guise of BPR - having led to the loss of precisely 
the knowledge and experience - the know how - that knowledge management stresses 
is a key contributory factor to organizational development and even survival. 

This apart, at present knowledge management is regarded in a positive light; 
although it has not suffered from the warp-speed hype that marked the emergence of 
BPR at the start of the 1990s. But whereas the component terms of BPR were fairly 
clear, the same does not apply to knowledge management. Many writers on 
knowledge management understandably seek to distance themselves from 
epistemology, but the question ’What is knowledge? has still to be asked. Moreover, 
in the context of information systems, one also has to ask other questions. ’What 
makes knowledge distinct from ’information? Is there some basis for thinking that 
the term knowledge’ is simply a redressing of the term ’information’, given that the 
latter seems inextricably linked to the electronic gadgetry of computers and 
communication systems? Furthermore, even if there is some reasonable and workable 
concept of knowledge’ in this novel context, what does it mean to manage 
knowledge? 
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2 Information and Knowledge 

1 do not intend trying to tackle the full intricacies of the distinctions between terms 
such as ’data’, ’information’ and ’knowledge’; but the issues and distinctions cannot be 
evaded completely. 1 would much rather dispense with the term ’data’ altogether. 
There is unease over its grammatical use - singular or plural? - and continuing dispute 
regarding the distinction between ’data’ and ’information’. The data-information 
couple lies at the basis of the ’chemical engineering metaphor’, where data is regarded 
as the raw material from which information is extracted. The inadequacies of this 
have been well documented, but the imagery continues to exert great influence. 

If there is any rationale for continuing to use the term data, then its only sense 
seems to be along the lines of ’something that is stored in objects’ - both inanimate and 
animate. Thus books, records, accounts, computer systems, CDs, disks and the like 
can be thought of as ’containing data’; but then so too do trees, plants, rocks, animals 
and people. Human beings do not, however, extract information from this raw 
material. As soon as humans turn their attention to any object, we are immediately in 
the realm of meaning. If it/they can be said to exist at all, data is the stuff that human 
beings are unaware of. 

People cannot engage directly in anything to do with data. Scanning a book into a 
computer is a data process; someone trying to read it - and make sense of it - involves 
information, because it inevitably involves meaning. Carbon-based entities are 
information-oriented; silicon-based ones are data-oriented. This is quite a helpful 
distinction in considering the project of ’artificial intelligence’, and dealing with 
claims that machines can become like humans. Thus one of the key criteria AI might 
have to fulfil for it to be judged ’successful’ would be a revised Turing test’, where the 
machine should also be able to distinguish between person and machine. 

Information comes about because animate entities - particularly human beings - 
construct meaning and exchange ideas in order to exist as social beings and interact. 
Meaning construction is a key activity in all human processes. A large amount of 
misunderstanding about the nature of this process of constructing meaning emanates 
from the metaphorical imagery in which discussions about this reside. This has been 
discussed elsewhere, particularly by Schon [2] and Reddy [3]; and has been 
specifically applied in the field of information systems and software engineering. 

The dominance of what Reddy terms the conduit metaphor, leads to the 
presumption that information flows around a system from source to target, from 
sender to receiver. This stresses the action of sending, and implies that receiving is a 
relatively passive process, at the most calling upon the repertoire of actions required 
'merely' for extracting or decoding. This metaphor also obscures the point that what is 
sent is a series of signals: information is created in devising the message and in 
interpreting it. Reddy makes the distinction between the signals and the selection 
processes that occur at both ends of the process. The thing that is sent is not the 
message but the signal; the message is what the sender wanted to communicate, and 
which may or may not correspond to the message derived by the receiver. Sending 
and receiving each require action and interpretation. 

The argument that meaning is continually constructed by social actors has been 
influentially stated and summarized by Giddens [4] in what he terms the 'theory of 
structuration'. He distinguishes between system and structure. Social systems are 
'composed of patterns of relationships between actors or collectivities reproduced 
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across time and space’ (p26); whereas structures ’have only a "virtual" existence’. This 
existence has a dual nature - the duality of structure - in the sense that the structure ’is 
both the medium and the outcome of the practices which constitute social systems’ 
(p27). 

This is not to say that social actors do this in an arbitrary fashion. On the contrary 
we continually test and seek to confirm our own sets of meanings. Meaning 
construction is a social activity, not an individual one. For the most part we do this all 
the time, without realizing that we are doing so. We only become conscious that we 
are doing this if someone draws our attention to it - as I am doing here; or if 
something ’goes wrong’, so that our implied or assumed meanings or ascriptions fail to 
receive support from the context or events. Information is then a human construct that 
arises from our actions as social beings producing and reproducing social systems 
against the capacities and constraints afforded by social structures. It also provides a 
resource for those actions. 

Giddens, writing in 1981 did not use the term information, but did talk about 
knowledgeable social actors’ and ’stocks of knowledge’. The latter are used by social 
actors ’in the production and reproduction of interaction’, being ’at the same time the 
source of accounts they may supply of the purposes, reasons and motives of their 
action.’ (p27) This knowledgeability ’is only partly discursive, as it is in part 
embedded in practical consciousness" (stress in original). 



2.1 Defining Knowledge 

So what does all this imply for the relationship and distinctions between information 
and knowledge? Many of the likely sources are not helpful. The epistemologists offer 
a variety of ideas about knowledge, but information is hardly a central focus - 
although this may change with the encroachment on to their domain that recent work 
on knowledge management represents. 

The knowledge management writers are also evasive on this, and many definitions 
of knowledge management’ could just easily be definitions of information 
management - or even general resource management. For example an article by two 
researchers based at The Cranfield School of Management in the UK offers a 
definition of knowledge management as ’the collection of processes that govern the 
creation, dissemination, and utilisation of knowledge to fulfil organisational 
objectives’ [5]. Replacing both occurrences of the word knowledge’ with 
’information’, ’software’, ’learning’ or a whole host of other terms (e.g. ’coffee- 
machine’) would still result in a meaningful statement, and so begs the question ’what 
is specific to knowledge that makes its management a specific and critical concern for 
organizations?’ To provide some basis for analysis a definition of knowledge is 
required, and cannot be avoided. 

For Davenport and Prusak [6] knowledge is defined as ’a fluid mix of framed 
experience, values, contextual information, and expert insight that provides a 
framework for evaluating and incorporating new experiences and information’ (p5). 
Zack [7] defines knowledge as ’that which we come to believe and value based on 
some meaningfully organized accumulation of information (messages) through 
experience, communication or inference’. Demarest [8] somewhat evades the issue by 
defining what he calls ’commercial knowledge’ - an explicitly developed and managed 
network of imperatives, patterns, rules and scripts, embodied in some aspect of the 
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firm, and distributed throughout the firm, that creates marketplace performances. 
While Schultze [9] notes that knowledge is an elusive concept, and so offers no 
definition, preferring Blackler’s idea of knowledge work - ’i.e. the work of producing 
and re-producing information and knowledge’ (p4) - note the conflation of 
information and knowledge. 

Meehan [10] in his brief survey of definitions of knowledge in the knowledge 
management literature, argues that definitions like Davenport and Prusak’s are heavily 
slanted towards a ’technical-rational’ view; and this can be contrasted with the ideas of 
Nonaka and Takeuchi [11]. Meehan terms their approach ’Japanese Knowledge 
Management’, and quotes their definition of knowledge approvingly - ’a dynamic 
human process of justifying personal belief towards the "truth"’. They also distinguish 
between information and knowledge in terms of ’flows’ and ’stocks’, so that 
information is what flows, and adds to knowledge stocks. Meehan points out that the 
Japanese approach links knowledge to action and subjectivity, and the authors 
specifically cite the work of social theorists such as Berger and Luckman whose book 
The Social Construction of Reality’ anticipates some of the main ideas proposed by 
Giddens. 

Given the range of meanings that can be attributed to the term ’knowledge’, and the 
ramifications these will have on subsequent arguments, the problem of defining the 
term cannot be evaded, even within the restricted realm of knowledge management. 
Yet perhaps we are all fooling ourselves by introducing the term. Maybe it is no more 
than a sophisticated epithet for information; and so any of the achievements around 
the ’1’ word can be readily applied to the K’ one. 

A hint of this can be found in the work of Davenport and Prusak. At the end of 
their book on knowledge management they note that some organizations are afraid to 
use the term ’knowledge’, and so resort to euphemisms such as best practice’, 
’experience’, ’information resource’ and so on. They quite rightly point out that this 
reluctance may well be indicative of an anti-intellectual stance that they term know- 
nothingism’. Using terms related to ’practice’ or pragmatics excludes many important 
aspects of modem processes. They then go on to state that - ’If you call it something 
related to information, you 11 be dragged back to the corporate information systems 
morass that really involves data’ (pi 74). This is rather a strange statement to find at 
the end of a book devoted to knowledge management. It really does appear to be 
something close to an admission that the entire concept of ’knowledge management’ 
has only come about because the term ’information management’ is now seen as 
predominantly or wholly focused on information technology. The term knowledge 
management then appears primarily as a corrective; drawing attention away from the 
technology towards other aspects - particularly the human and organizational ones. As 
a minimal basis for focusing on knowledge rather than on information, it seems a 
sensible solution, although perhaps not exactly what Davenport and Prusak actually 
had in mind: But at least there is a minimally valid reason to go with the K word. 
There is, however, always the tendency for technicist reasoning to intrude, and it may 
not be long before ’knowledge-technology’ takes on a role similar to IT, and the ’K- 
word’ has to be replaced by a new euphemism such as ’wisdom’, ’experience’, or 
’intelligence’. (A search across the web indicates that this is already happening.) 

So at the very least we can be reconciled to the idea of knowledge in its presently 
popular embodiment in knowledge management. If it moves people’s attention away 
from the technology, and helps them resolve issues at the human, organizational and 
social level, then this is to be welcomed. There is a problem, however, in linking 
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knowledge to management. The term ’management’ is not a neutral one; it comes 
with a set of conceptual baggage that evokes tendencies towards hierarchies, 
structures, and control: The classic if discredited command-and-control orientation. 
Management has an inherently mechanistic tendency; the terms and imagery of 
management writing are slanted towards a rationalistic view of planning, strategy, 
decision-making, allocations and so on. Management seems wedded to objects - 
animate and inanimate - and is not very good at dealing with animate ’subjects’, 
meaning and process. 



3 The Process Perspective 

Taking this as a starting point, many of the management ’fads’ of the 1990s can be 
seen originating in attempts to move away from the mechanistic disposition. TQM, 
BPR, Process Improvement all stress the concept of ’process’ as central; in some cases 
explicitly moving away from products and objects. But this is not an easy task; people 
find it far easier to conceptualize and abstract in terms of ’things’ or ’objects’ than they 
do in terms of ’processes’. A closer examination of the ’fads’ of the last 10-20 years 
reveals a more complex picture. Many of these ’fashions’ really did originate from 
genuine insights that, if not entirely new, certainly offered a different perspective on 
key issues. Such insights, however, are always in danger of dissipation once they 
become re-interpreted in line with older, predominant conceptions. This may be 
inevitable, since people will always try to understand something new in terms of what 
they already know. What has been particularly noteworthy with some of the 
’innovations’ of the 1980s and 1990s is that the originators of the ideas themselves 
have often been the worst perpetrators of this. Mike Hammer may be the name that 
everyone associates with BPR; but there is a good case to be made that he was also its 
worst publicist. He practically admits this in his later work; similarly Davenport’s 
renunciation of BPR [12]. 

What both Hammer and Davenport have stressed, however, is that the key aspect 
of the ideas around BPR was process. Davenport has sought to develop his approach 
to knowledge management precisely along the lines of knowledge as a process, not as 
an object. Yet he continues to undermine his own position; having confirmed the 
process nature of knowledge, and defined it in terms of a human quality, Davenport 
and Prusak state that ’[N]ot only can it [knowledge] judge new situations and 
information in the light of what is already known, it judges and refines itself in 
responses to new situations and information’ (pll, quoted by Meehan, p5, his stress 
added). Here is knowledge as a disembodied object; and most definitely not a 
socially-constructed, human-centred process. 

I believe that this problem arises because people find process abstractions and 
process concepts far more difficult than product or object ones. This may be a 
culturally specific disposition, but it certainly seems present in Europe and North 
America. Some evidence to support this comes from a consideration of object 
orientation, which was heralded as a conceptual advance on entity modelling because 
it was allegedly more ’natural’ and congruent with the ways in which we think [13]. 
Objects were seen as a combination of product and process, superseding the data- 
oriented entity-relationship approaches. Yet the revolution promised by 00 never 
really materialized, although there were some definite benefits. To some extent the 
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00 enthusiasm of the early 1990s has given way to ’component’ development, which 
is inherently based around objects in the tangible sense of the term, and where process 
is still a poor relation. 

To substantiate the claims of the previous paragraph I really need to give ground to 
those with expertize in cognitive psychology. They might be able to offer 
explanations why humans seem inherently drawn towards object abstractions rather 
than process ones. For my present purposes, however, I simply wish to state the view 
that this tendency does seem to exist, and needs to be taken into account when 
considering how best practice in our field can be put into effect. When we come to 
look at BPR, knowledge management and so on, it is vital that we continually fight 
against any inclination towards object-centred, mechanistic and technicist thinking - 
we might call the tendency thingking: And so I want to develop some ideas that might 
help remedy this - hence my title, which 1 shall now explain in more detail. 



4 Rules, Events, and Dramas 

A few years ago I might have had to explain and justify the introduction of the work 
of anthropologists and cultural theorists to this sort of audience. I will still not take it 
for granted that my specific sources are ’obvious’, but following the work of people 
such as Boisot, Suchman, and Zuboff [14,15,16], it is perhaps less surprizing to draw 
upon such work. 

The anthropologist Clifford Geertz conducted various fieldwork visits to Bali in 
the 1950s and 1960s. Some of his findings were published as part of a collection of 
essays called The Interpretation of Cultures’, and the essay on cockfighting has 
become widely read and cited. The full title of the essay is ’Deep Play: Notes on the 
Balinese Cockfight’ [17]. 

Geertz noted that when he and his wife arrived in a fairly remote village in Bali - ’it 
was its own world ... we were intruders, professional ones'. The Balinese dealt with 
us 'as though we were not there ... we were non-persons, spectres'. Their 
accommodation had been arranged by the provincial government, and was located in 
an 'extended family compound ... belonging to one of the four major factions in 
village life'. Apart from the landlord and village chief (the landlord's cousin and 
brother-in-law) 'everyone ignored us in a way only a Balinese can do ... people 
seemed to look right through us with a gaze focused several yards behind us'. The 
villagers knew who they were, but they acted as if the American academics did not 
exist. Any interaction only occurred if it was absolutely unavoidable, and then was 
cursory at best - a few short responses to questions or simply non-verbal ones. 

The breakthrough came as a result of a cockfight in the village. The cockfight is 
technically illegal; but in the same way that alcohol was illegal in the US during 
prohibition; or certain drugs such as marijuana are illegal now. Geertz and his wife go 
along to watch the fight - although they are still ignored. But during the fight the 
police arrive and the whole village descends into chaos as people flee the scene to 
escape questioning and possible arrest. Geertz and his wife join in the flight away 
from the scene. They follow a man into his compound, where the man's wife 
magically produces a table and settings for tea, and by the time the police come 
around they are all sitting drinking as if they had spent the entire afternoon there. 
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The policeman’s attention is taken by the scene of a villager and two obvious 
foreigners sitting together outside his dwelling. The policeman approaches them and 
asks what has been going on. The villager, much to the surprize of Geertz and his 
wife, explains in great detail to the policeman that they are two famous anthropology 
professors from America, studying Bali with the permission of the local government; 
and that they have been discussing the local culture with him all afternoon. The 
policeman retreats, too amazed to utter another word, and a short time later so too do 
the equally dumbfounded anthropology professors. 

The next day brings about a complete change in their position. People speak to 
them. In fact everyone goes out of their way to engage them in conversation, and ask 
for a recounting of their experience of the day before. They are asked why they 
simply did not stay where they were, pull out their papers and protest their innocence 
and non-involvement. They are treated as members of the village, rather than 
outsiders. They are complimented for their show of solidarity, although Geertz 
confides to the reader that their joining with the fleeing spectators was more a result 
of cowardice than bravado. They are also teased for their inelegant style of running; 
but for the Balinese being teased is a sign of being accepted. 

The parallels between Geertz’ position and that of a knowledge practitioner 
(however defined) investigating a new organizational context are readily apparent. 
They each have a form of authority derived from a hierarchical source, but this does 
not guarantee acceptance; and even acceptance is hardly sufficient for gaining real 
insight into the context and characters involved. There is a barrier to any interaction, 
and a simultaneous stance of complete indifference coupled with intense interest in 
the nature and characteristics of the outsiders and their objectives. For Mr and Mrs 
Geertz the barriers were removed in dramatic fashion. The possibility of a series of 
occurrences such as those that surrounded the cockfight is perhaps rather low in more 
mundane circumstances, and may not necessarily be very welcome by any of the 
participants. 

What the episode does show, however, is that certain transitions are necessary for 
’outsiders’ to gain some insight into unfamiliar systems; and that such transitions are 
not necessarily amenable to ’rational’ or ’instrumentaP manipulation. Even had Geertz 
had an inkling of the role of the cockfight in the Balinese context, there was no way 
that he could have initiated the series of occurrences that took place. Indeed he readily 
admits that only in the aftermath of the cockfight, and the access this gave him to the 
village, did he gain a real understanding of the role played by the fight, and more 
particularly by the betting. 

What Geertz’ experience does begin to demonstrate is that some form of dramatic 
incident - or set of incidents - may well illuminate the complexities of a context or 
system far better than any ’detailed analysis’. This is hardly surprizing since at such 
points of ’rupture’ people will be unguarded or unprepared, and so their responses may 
well be less inhibited by convention and other constraints - social, cultural, 
organizational. 

Those writers who assume that the nature of business processes and tacit 
knowledge is simply amenable to rational analysis, discourse and participation 
between and among all parties fail to account for the sorts of barriers that Geertz 
encounters. I am not suggesting that similar incidents should be provoked or 
precipitated, but I do want to suggest that understanding alien systems - village, sub- 
culture, or organization - takes different forms, and that some levels of understanding 
may not be amenable to outsiders. Knowledge practitioners will have to recognize the 
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limitations of their position, accept the non-rational aspects of knowledge contexts, 
and adapt their practices and analyses accordingly. 

To being with, there must be recognition of a range of understanding. This range 
might be thought of as extending from an analysis of rules, routines, regulations 
through events and effects to full scale dramas, similar to the one that opened up the 
Balinese experience to Geertz. Rules, routines, and regulations will tend to provide 
understanding in terms of structures, with perhaps some hint of function. In general, 
however, focusing on this level will tend towards a formal and static view of a 
context. It is also closely related to the idea that intelligence is a matter of following 
rules: A view associated with Herbert Simon, potently and convincingly dismantled 
by the critique of Dreyfus and Dreyfus [18]. Contexts cannot be fully grasped simply 
by studying the rules that actors follow, or say they follow. Again this resonates with 
Giddens’ point about actors using stocks of knowledge to explain their actions, but 
this is only ’partly discursive’, with some aspects being embedded in ’practical 
consciousness’. 

Analysis of events and their accompanying effects provides a less static view; 
although there is still the danger of lapsing into functional hierarchies; precisely the 
sorts of functional rigidity that BPR set out to subvert. But it must be pointed out that 
this sort of analysis and abstraction is often strongly resisted by analysts, as can be 
seen in their use of methodologies that attempt to provide approaches precisely for 
this type of model. 

A combined study that seeks to account both for rules and events will go some way 
to reach an understanding; but the Geertz example indicates that more dramatic 
incidents may ultimately open up far more of a context to an outsider. Only in such 
dramas is there the full richness of a dynamic view of a system; albeit episodic and 
tending towards anecdote. This may possibly provide a series of interesting narratives, 
but at an indeterminate level of generalization. 

Across the three levels there needs to be a balance between the generic, static and 
rather formal rule-oriented aspect, and the narrative-based and specific dramatic one. 
These facets can be seen as ways of gradually coming to an understanding of different 
levels of a culture, such as those mentioned by Trompenaars and Hampden-Tumer 
[19]. They offer a model of three levels of culture. 

- The outer layer - consisting of artefacts and products; the most explicit and 

amenable of the three; 

- the inner layer - constituted from norms and values - ’the mutual sense of what is 

right and wrong’, and what is good and bad; 

- the innermost layer - the basic assumptions and core beliefs. 

The first two layers are important, and may well be the resources that actors draw 
upon to explain and justify their actions and accomplishments. Process modelling and 
knowledge management must focus on these; but this is not sufficient, and the 
innermost layer must somehow be uncovered and rendered amenable to study. By 
definition the innermost layer will be resistant to such analysis. The conventional - 
rationalistic and instrumentalist - techniques simply will not lend themselves to 
exposing these features in a domain. They may only become amenable at times of 
crisis or drama, and it is here that much of what the knowledge management writers 
describe as ’tacit knowledge’ - similar to Giddsns" practical consciousness - may well 
reside. 
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Geertz puts the matter succinctly when he states that investigating cultures at this 
level is a case of social semantics, not social mechanics (p448); i.e. we are firmly 
embedded in the realm of meaning, not mastery. 
Furthermore he stresses that the narratives around the cockfight show the Balinese 
telling a story about themselves to themselves; and this aspect is largely omitted from 
current ideas about knowledge management with its overly and overtly rationalist 
concept of knowledge about knowledge. To comprehend any context requires the full 
range of these perspectives, but this is not to argue that ’comprehension’ is the same as 
participation or membership. Geertz does not become a Balinese village member; nor 
a member of one of the four factions in the village. 

It is not being suggested that ’outsiders’ have to immerse themselves so completely 
in the context that they become members or participants. On the other hand, maybe 
knowledge practitioners need to take more heed of anthropological and other practices 
- e.g. soft systems and other OR methods - that do indeed stress something along 
these lines when they talk about becoming one of the ’problem owners’, or ’problem- 
context owners’. It is surely important that there is some recognition of this paradox at 
the heart of any truly human-centred attempts to gain insight into the knowledge 
practices of others. 

What 1 am stressing is that we have constantly to battle to overcome the tendency 
to remain at levels of analysis that are based around static structures - looking for 
rules, regulations, roles. This limitation is not always evident and easy to overcome as 
our use of language tends to push us in this direction - well it certainly does in 
English. 

In order to draw out the full implications of knowledge management or knowledge 
engineer ing‘ processes we have constantly to stress the process aspects; and this is not 
as easy as stressing the structural ones. Models tend to accentuate the static. It is more 
difficult to model dynamic aspects; and even if a specific person can produce such a 
model to their satisfaction, it is likely that others will undermine its dynamic aspects 
in their use or interpretation of the model. DFDs, Petri-nets, State Transition 
Diagrams, Action diagrams. Use Cases; all have been heralded as breakthroughs in 
grasping some of these complexities. But in practical application most people fail to 
construct or use them correctly. CRC cards and scenarios work a little better, and this 
may well be because they are based on something close to the dramatic aspect 
mentioned earlier. Perhaps this is why people can often model and communicate 
around the dynamic/process aspects of a context once they have spent some time 
looking at it in this fashion. 



5 Deep Play 

Some of the most interesting aspects that Geertz actually discovers about cockfighting 
are connected with the gambling and betting that surrounds the activity itself Indeed 
he quickly finds that the spectacle of the fight is secondary to the betting. To 
understand the importance of the betting, Geertz introduces the concept of ’deep play’ 
into his analysis. 



' See [20] for an outline of the argument why ’engineering’ may not be an appropriate or useful 
term in this and related contexts. 
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Deep play’ is a term used by the IS"* century English Utilitarian philosopher 
Jeremy Bentham in his work The Theory of Legislation’. He sought to establish a 
fully rational basis for legislation, and defined ’deep play’ as betting where the stakes 
are so high that it is actually irrational for anyone to participate. If you bet half of 
what you own on a bet at odds of 1 : 1 (evens), then the risk of losing far outweighs 
any possible gain: Think of doing the same with half of your house. 

Bentham actually wanted such ’immoral behaviour’ made illegal. Yet Geertz 
discovers that the Balinese regularly engage in this form of betting - what he calls 
’centre betting’. This is because such behaviour is bound up with status, honour, 
dignity and respect. The money is still important, but it is not the only measure of 
things. There is an over-riding sense of importance - of meaningfulness - to the 
betting. It is done very publicly. As Geertz notes, the bravado of staking such large 
amounts is literally ’putting one’s cock on the line’; and the word ’cock’ in Balinese has 
the same wide set of meanings as it does in English. The cockfight is actually what 
Goffman would call ’a status bloodbath’. 

What Geertz shows is that if one tries to understand the Balinese practices of 
betting in a Benthamite (rationalistic) manner, then one will fail to grasp its essential 
aspects; one has to move from Bentham’s realm of ’utility’ to Weber’s one of 
’meaning’. This has such obvious significance for knowledge management, that its 
ramifications ought to be a central aspect of any associated practices. 

The issue is not one of an outsider ’dissecting’ a complex set of practices into a 
base notation of simple actions and beliefs, that can be used as some universal 
yardstick against which everything can be assessed. We are not in the realm of 
measurement and mechanism; we are in the realm of meaning, interpretation, 
dialogue and understanding. This is a critical point to be borne in mind for those of us 
involved in knowledge management and process analysis. 

This point is clearly and forcibly made by Geertz - the involuntary participation in 
the drama of the Balinese cockfight was indispensable to his later access to the 
village. We may not always be able to arrange dramas of this kind; and so must 
always be aware of the partial nature of our ’findings’ - partial in the sense both of 
being incomplete and of being biased or slanted. 



6 Chinese Encyclopaedias - From Anthropology to Archaeology 

How does all this relate to Chinese encyclopaedias? In his essay The Analytical 
Language of John Wilkins’, Borges writes of the encyclopaedia ’discovered’ by John 
Wilkins 

On those remote pages it is written that animals are divided into (a) those that belong to the 
Emperor, (b) embalmed ones, (c) those that are trained, (d) suckling pigs, (e) mermaids, (f) 
fabulous ones, (g) stray dogs, (h) those that are included in this classification, (i) those that 
tremble as if they were mad, (j) innumerable ones, (k) those drawn with a very fine camel’s hair 
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brush, (1) others, (m) those that have just broken a flower vase, (n) those that resemble flies 
from a distance.^ 

This extract has appeared in the knowledge management literature, used by several 
authors to make a range of different points. Marc Demarest notes that although it may 
look bizarre to us, ’it must have worked for the Chinese’. Demarest, like many other 
writers on knowledge management, tries to circumvent the philosophical issue of 
’what constitutes knowledge?’ He distinguishes between scientific and philosophical 
knowledge and commercial knowledge, defining the latter as follows - ’good 
commercial knowledge is knowledge that works ... Its truth value is incidental to its 
ability to generate desirable commercial performances' (p3). Demarest stresses that 
his discussion is only focused on 'commercial knowledge', distinct from scientific and 
philosophical knowledge, and that this is a form of knowledge that has pragmatic 
value, with criteria based around performance rather than correctness or validity. 

Following the extract from Borges, this raises more questions than it answers. If 
we look closely at the extract from the Chinese Encyclopaedia we can see there is no 
way that the classification can have 'worked' at a rational level, since it is inherently 
paradoxical. For instance look at categories (h) and (1). In any case why should the 
encyclopaedia be classed as commercial knowledge? Surely the concept of 
commercial knowledge as a distinct category is one that only begins to make some 
sense to us in the 1990s, and would have been totally alien to the authors of the text 
itself? 

This is not to take some lofty view that consigns the extract and the encyclopaedia 
to the tray marked 'interesting but not really useful'. Demarest may well be correct to 
note that the classification was a useful way of ordering things for the people 
concerned; but that really misses a number of key points. 

- Any written text may not accurately represent what was actually 'used' by the 
people themselves. After all cockfighting was illegal in Bali, but there certainly 
was a written statute banning it. 

- The entry may well summarize what people believed, even though their real 
actions and underlying assumptions were entirely different. They may not have 
been dismayed by the paradox and discontinuities, just as people in the UK 
continue to play the lottery twice a week, even though the odds are so dramatically 
stacked against them. In fact what they are really doing is paying a highly 
regressive form of tax. 

- Wilkins may have misunderstood what was actually written down in the first place, 
and/or the process of translation from an ideographic representation to a character- 
based one may have resulted in a mistaken interpretation of the original. (This is a 
critical point for IT-based 'solutions' for knowledge management.) 

- The 'data' - the Chinese ideographs - may have been drawn with an entirely 
different set of meanings than those derived by Wilkins or later readers. 

- Borges may well have made up the entire extract; quite likely given his genius for 
imaginative writing. In this case Wilkins may never have existed; or if he did, he 
may never have discovered such an encyclopaedia. This is not to say that such an 



^The essay can be found in Borges’ collection Other Inquisitions', but I have taken the extract 
directly from Foucault’s text, where it is used with out giving the exact reference. I am 
grateful to Marc Demarest for supplying me with the full reference. 
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encyclopaedia does not exist - it may well do so; but no-one may actually have 
discovered it. Here we have an instance where the information exists, but perhaps 
without any data. 

- The logical paradoxes may only exist in particular cognitive systems. In others, 
categories such as (h) and (1) may happily and consistently co-exist. 

All of which means that extracts such as that from Borges are double-edged when 
introduced into discussions of knowledge management. We have to recognize that 
Borges’ irony can be understood to apply equally to ourselves. Our classifications, so 
’obvious’ and ’commonplace’ that they are hardly noticeable, may appear equally 
strange and contradictory to others; and if that is the case why should these ’others’ 
only be those from later times and far off places? What do people from other cultures 
think of our problems with categories of data, information, and knowledge? What 
might people in future make of such discussions? 

Crucially, to what extent are our current debates around ’knowledge’ - object, 
process, technology, social, etc. - critically influenced by the terminology itself? 
After all in French there are at least two words associated with knowledge and 
knowing - savoir and connaitre; German also offers a number of words that are often 
translated simply as ’knowledge’. Other languages may well exhibit similar ranges of 
words, and it may be that some of the difficult conceptual issues of knowledge 
management simply disappear if we move away from the English terminology. 

Again, here we have a clear basis for feeling uneasy about mechanistic approaches 
to knowledge management. Such ’recipes’ for knowledge management fail to take 
account of this ’definite strangeness’. But this should not be taken to mean that 
knowledge management is an impossibility. On the contrary it locates knowledge 
management as a critical, social endeavour. Moreover it means that we have to move 
beyond Davenport and Prusak’s concern that we simply distance it from the 
technology. We must positively move towards existing work in linguistics, 
philosophy and cultural theory. 

Perhaps the most notable use of the extract from Borges was by the cultural 
theorist Michel Foucault in his book Ees Mots et Les Choses’ - in English published 
as The Order of Things’ [21].^ Foucault argued that the very categories of knowledge 
were not something that arose from the ’mercy of chance’ 

. . . what if empirical knowledge, at a given time and in a given culture, did possess a well- 
defined regularity? ... If errors (and tmths), the practice of old beliefs, including not only 
genuine discoveries, but also the most naive notions, obeyed, at a given moment, the laws of a 
certain code of knowledge?' (p ix) 

Foucault’s point is that knowledge is not something that simply grows as extra items 
are added to an amorphous pile. The imagery of a ’stock of knowledge’ is misleading. 
The way we see things and demarcate between them is culturally bound. The ’things’ 
are themselves part of a far more complex set of cultural cognitive processes. 

Foucault subtitled his book, ’an archaeology of knowledge’, and perhaps the idea of 
archaeology applied to knowledge artefacts affords a critical insight that might help 
us guard against the tendency to mechanistic - and technology-centred - views of 
knowledge management: Instead pushing us firmly towards the social and cultural 
bases of knowledge. This in turn may cause us to revise or even reject the concept of 



^ This was not a mistranslation, there were already at least two other books in print with the title 
'Words and Things'. 
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knowledge management, since our goal becomes one more concerned with achieving 
insight rather than that of ’making better use of knowledge resources’."* The irony is 
that we may be slowly moving toward the recognition that in order to achieve the 
latter we really do have to move towards the former, and that quick-fix technological 
’solutions’ are inadequate and inappropriate. Anthropology and archaeology may well 
be two of the most important resources for effective knowledge management. 
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Abstract. We present here a groupware (MEMO-Net) based on a model 
(DIP A), which uses and simplifies the concepts of Problem-Solving methods. 
This model comes from a review of Design Rationale formalisms that gave rise 
to the ABRICo formalism. MEMO-Net enables exchange structuring in order to 
improve dialog quality and reusability. MEMO-Net prefigures a new KM 
approach, named “cooperative KM” where we propose virtual work 
environments for groups that will consist in new “coordination mechanisms”. 



1. Introduction 

In accordance with Zacklad and Grundstein [17], we can classify knowledge 
management (KM) approaches in three complementary categories: top-down, bottom- 
up and cooperative. In the first one, models are used with experts to formalize their 
knowledge (MKSM for example). In the second one, huge corpus are memorized and 
formalized afterwards (text-mining methods). And in the third one, we consider that 
organizations’ critical knowledge comes within a collective competence that is not 
enough or badly formalized. 

Groupwares generally use two kinds of models to structure interactions and to 
manage knowledge in organizations: some of these models allow a relationship 
standardization instead of others that focus on know-how standardization [18]. 

Among models based on relationship standardization, we can quote the famous 
Speech-Act theory from Winograd and Flores [15] and its derivative [6]. These 
models allow a more efficient management of contractual processes in firms. They fit 
in KM strategies focused on “commitment traceability”. On the other hand, models 
used for decisions’ traceability in the scope of know-how standardization are closer to 
Design Rationale (DR) researches. In these studies, models are decision oriented. We 
can quote QOC [9] or IBIS [1]. 
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In a previous study [8], we came to the conclusion about the difficulty of applying 
some DR models in complex collective design situations. In this paper we propose to 
use problem-solving methods to organize the traceability of decision-making 
processes, particularly in design situations. Problem-solving methods are going to 
help the formalization of argumentation in collective problem solving situations. 



2. CSCW and Knowledge Management 

Our approach comes within the scope of cooperative approaches where one considers 
that crucial knowledge is held by groups. If we want to capitalize on this exchanged 
knowledge, we have to focus on existing communication processes in the firm. Two 
approaches are possible faced with this problem: Memorizing all the interactions and 
then building a thesaurus on the base of the corpus or playing a part during the 
communication process by a priori structuring information. 

The second option is the one that we have chosen. This interest in a priori 
structuring of problem-solving processes in order to guarantee exploitation is not 
recent. In CSCW (Computer- Supported Cooperative Work) research, several authors 
[3], [4] have already expressed the wish to switch from a “object-centered paradigm 
to a “process-centered” paradigm. In the latter, designers’ interaction (that is to say 
questions, decisions and conversations that form the elaboration environment of the 
objects) would be memorized as well as objects and design process results. This 
paradigm is the one of DR researches, of which experimentations can be classified in 
two groups: A posteriori DR whose drawbacks are the need of a project memory 
leader during the project and meetings with all the people of the project after the 
project [7]. Or DR following the current, with tools such as QuestMap for example 
[10]. 

Our approach is near the second group although we have shown [8] that DR 
models are pertinent for some situations but are sometimes far from real design 
situations in which we construct step by step a solution instead of choosing or sorting 
several options. Our aim is to propose more realistic models from a cognitive point of 
view but not too far from concrete design situations which people are confronted 
with. In order to approach the cognitive dimension of reasoning we propose to use 
problem-solving method concepts from knowledge engineering. 



3. Problem-Solving Models and Design Rationale 

Actually, we could say that Design Rationale models have neglected the 
“information” phase of Simon’s decision-making process [13], and have only taken 
into account the solutions selection phase. Models from Artificial Intelligence do not 
have this fault. This link with problem-solving methods seems to us a natural 
evolution in our researches of more realistic Design Rationale models suited to the 
complexity of real projects. 

We have then built a model called DIPA (from the French words Donnees, 
Interpretations, Propositions, Accord, meaning facts, interpretations, propositions. 
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agreement) where problem-solving models replace decision-making processes, even 
complex ones. 

The model comes in two forms, according to the situations that lead the actors to 
give priority to either analysis or synthesis processes (for example as in KADS 
methodology) [14], 

This reference to problem-solving models allows the integration of an important 
knowledge category that was not taken into account in the two previous models, the 
“problem data”. In the DIPA model, the reasoning progresses in three major steps: 

• a problem description step plus collecting of data, considered as symptoms in 

analysis situations and as needs in synthesis situations 

• an abstraction step going from the collecting of problem data to their interpretation 

corresponding to a possible cause in analysis situations, and to a functionality in 
synthesis situations; 

• an implementation step that going from an interpretation (cause or functionality) to 

the elaboration of a proposition that is a corrective action removing the 
symptom’s cause (analysis) or the means suitable for the expressed functionality 
(synthesis) 

The fact that we had to present both analysis and synthesis models to designers 
teams may seem amazing. Actually, it might appear natural at first glance to propose 
only synthesis models and their variants (routine design, configuration...). But our 
practical experience of design meetings revealed us that analysis activities are 
frequent. For example, as soon as a prototype has been developed, its function 
analysis will give important information that will be reintroduced in the process of 
solution finding. 

These observations are also in accordance with cognitive ergonomic psychology 
[5] results that teach us that design situations in the organizational sense in fact 
generate two distinct phases of activity: solution generation and then evaluation of 
these solutions. The first corresponds to synthesis problems in a KADS sense and is 
close to design models in this method. The second corresponds to analysis problems 
whose diagnosis models are well-known. 

This idea of a unique model (figure 1) to represent the two types of activity is quite 
close to some interpretations of the heuristic classification of Clancey [2]. According 
to Zacklad and Fontaine [16], in both types of situation, there is both exploitation of 
knowledge from previous solved cases, and construction of an original solution. This 
solution is a proof or a justification in analysis case and a constraints-compatible 
approximate solution in synthesis cases. 

Whereas, in the DIPA model, the abstraction and implementation inference steps 
are two symmetrical aspects of the same heuristic reasoning, applicable both in 
analysis and synthesis. In abstraction cases, for example, the point of view about any 
one system will change according to whether the symptoms or their causes are 
considered most important, or even the requirements of internal system functions. 

The formalism used to describe DIPA was inspired by KADS [12], [14] but does 
not strictly follow the KADS conventions as to how to represent inference structures. 
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Fig.l: DIPA, a heuristic model of design reasoning for analysis and synthesis and its 
implementation for synthesis and analysis activities (table) 






